View SN260_4517639.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

SN260
ZigBee(R) 802.15.4 network processor
Features

Integrated 2.4GHz, IEEE 802.15.4-compliant transceiver: - Robust RX filtering allows co-existence with IEEE 802.11g and Bluetooth devices - - 97.5dBm RX sensitivity (1% PER, 20byte packet) - + 3dBm nominal output power - Increased radio performance mode (boost mode) gives -98.5dBm sensitivity and +5dBm transmit power - Integrated VCO and loop filter - Secondary TX-only RF port for applications requiring external PA. Integrated IEEE 802.15.4 PHY and MAC Dedicated peripherals and integrated memory EmberZNetTM ZigBee(R)-compliant stack running on the dedicated network processor
Controlled by the Host using the EmberZNetTM Serial Protocol (EZSP) - Standard serial interface (allows for connection to a variety of Host micro controllers) Non-intrusive debug interface (SIF) Integrated hardware and software support for InSight Development Environment Provides integrated RC oscillator for low power operation Three sleep modes: - Processor idle (automatic) - Deep sleep--1.0A - Power down--1.0A Watchdog timer and power-on-reset circuitry Integrated AES encryption accelerator Integrated 1.8V voltage regulator Compatible with Ember EM250
TX_ACTIVE

PA select
RF_TX_ALT_P,N
PA SYNTH PA DAC MAC + Baseband
PacketTrace
RF_P,N BIAS_R OSCA
LNA Bias
IF
ADC
Network Processor (XAP2b)
Encryption acclerator HF OSC
Network Processor Peripherals Integrated Flash and RAM
OSCB
Internal RC-OSC Serial Controller Interrupt Controller
Always powered Sleep timer
POR
nRESET SIF_CLK
VREG_OUT
Regulator Chip manager
Watchdog SIF
SIF_MISO SIF_MOSI nSIF_LOAD
IO Controller
MISO
nSSEL_INT
nSSEL
SCLK
MOSI
nWAKE
nHOST_INT
December 2007
Rev 2
LINK_ACTIVITY
PTI_DATA
PTI_EN
SDBG
1/88
www.st.com 1
Contents
SN260
Contents
1 2 3 4 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Pin assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Top-level functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 4.2 4.3 4.4 4.5 4.6 Absolute maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Recommended operating conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Environmental characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 DC electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Digital I/O specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 RF electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6.1 4.6.2 4.6.3 Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Synthesizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Receive (RX) path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1 5.1.2 RX baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 RSSI and CCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2
Transmit (TX) path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1 5.2.2 TX baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 TX_ACTIVE signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 5.4 5.5 5.6
Integrated MAC module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Packet trace interface (PTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 16-bit microprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Embedded memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6.1 5.6.2 Simulated EEPROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Flash information area (FIA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.7 5.8 5.9
Encryption accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Reset detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Power-on-reset (POR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2/88
SN260
Contents
5.10
Clock sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.10.1 5.10.2 High-frequency crystal oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Internal RC oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.11 5.12 5.13 5.14
Random number generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Watchdog timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Sleep timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Power management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6
SPI protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1 6.2 Physical interface configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 SPI transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 Command section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Wait section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Response section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Asynchronous signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Waking the SN260 from sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Error conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3 6.4 6.5
SPI protocol timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 SPI byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5.1 6.5.2 Primary SPI bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Special response bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6 6.7
Powering on, power cycling, and rebooting . . . . . . . . . . . . . . . . . . . . . . . 29
6.6.1 Unexpected resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Transaction examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.7.1 6.7.2 6.7.3 6.7.4 SPI protocol version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 EmberZNet serial protocol frame -- NOP command . . . . . . . . . . . . . . . 30 SN260 reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Three-part transaction: Wake, Get Version, Stack Status Callback . . . . 32
7
EmberZNet serial protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1 7.2 Byte order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Conceptual overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.1 7.2.2 Stack configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Policy settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3/88
Contents 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7 7.2.8 7.2.9
SN260 Datagram replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Power management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 SN260 status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Random number generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3
Protocol format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7 7.3.8 7.3.9 Type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Structure definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Named values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Configuration frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Utilities frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Networking frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Binding frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Messaging frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Alphabetical list of frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.4
Sample transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.4.1 7.4.2 7.4.3 7.4.4 Joining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Sending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Receiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8 9 10 11 12 13 14
SIF module programming and debug interface . . . . . . . . . . . . . . . . . . 81 Typical application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Mechanical details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4/88
SN260
General description
1
General description
The SN260 integrates a 2.4GHz, IEEE 802.15.4-compliant transceiver with a 16-bit network processor (XAP2b core) to run EmberZNet, the ZigBee-compliant network stack. The SN260 exposes access to the EmberZNet API across a standard SPI module, allowing application development on a Host processor. This means that the SN260 can be viewed as a ZigBee peripheral connected over a SPI. The XAP2b microprocessor is a power-optimized core integrated in the SN260. It contains integrated Flash and RAM memory along with an optimized peripheral set to enhance the operation of the network stack. The transceiver utilizes an efficient architecture that exceeds the dynamic range requirements imposed by the IEEE 802.15.4-2003 standard by over 15dB. The integrated receive channel filtering allows for co-existence with other communication standards in the 2.4GHz spectrum such as IEEE 802.11g and Bluetooth. The integrated regulator, VCO, loop filter, and power amplifier keep the external component count low. An optional highperformance radio mode (boost mode) is software selectable to boost dynamic range by a further 3dB. The SN260 contains embedded Flash and integrated RAM for program and data storage. By employing an effective wear-leveling algorithm, the stack optimizes the lifetime of the embedded Flash, and affords the application the ability to configure stack and application tokens within the SN260. To maintain the strict timing requirements imposed by ZigBee and the IEEE 802.15.4-2003 standard, the SN260 integrates a number of MAC functions into the hardware. The MAC hardware handles automatic ACK transmission and reception, automatic backoff delay, and clear channel assessment for transmission, as well as automatic filtering of received packets. In addition, the SN260 allows for true MAC level debugging by integrating the Packet Trace Interface. An integrated voltage regulator, power-on-reset circuitry, sleep timer, and low-power sleep modes are available. The deep sleep and power down modes draws less than 1 A, allowing products to achieve long battery life. Finally, the SN260 utilizes the non-intrusive SIF module for powerful software debugging and programming of the network processor. Target applications for the SN260 include:

Building automation and control Home automation and control Home entertainment control Asset tracking
The SN260 can only be purchased with the EmberZNet stack. This technical datasheet details the SN260 features available to customers using it with the EmberZNet stack.
5/88
Pin assignment
SN260
2
Pin assignment
Figure 1. SN260 pin assignment
VDD _SYNTH _PRE
L IN K _ A C T IV IT Y
VDD _24M HZ
VDD _FLASH 32
VDD _CO RE
nW AKE
OSCA
OSCB
SDBG
40 VDD_VCO R F_P RF_N VDD_RF RF_TX_ALT_P RF_TX_ALT_N V D D _ IF B IA S _ R VDD _PAD SA T X _ A C T IV E 1 2 3 4 5 6 7 8 9 10 11
39
38
37
36
35
34
33
31 30 29 28 27 n S IF _ L O A D S IF _ M O S I S IF _ M IS O S IF _ C L K n H O S T _ IN T RES VDD_PAD S P T I_ D A T A P T I_ E N nSSEL
41 GND
EM 260
SN260
GND 26 25 24 23 22 21 20 SCLK
12
13
14
15
16
17
18
19
VREG _O UT
nRESET
n S S E L _ IN T
VDD_PAD S
M OSI
RES
VDD_C O R E
Table 1.
Pin # 1 2 3 4 5 6 7 8 9 10
Pin descriptions
Signal VDD_VCO RF_P RF_N VDD_RF RF_TX_ALT_P RF_TX_ALT_N VDD_IF BIAS_R VDD_PADSA TX_ACTIVE Direction Power I/O I/O Power O O Power I Power O 1.8V VCO supply Differential (with RF_N) receiver input/transmitter output Differential (with RF_P) receiver input/transmitter output 1.8V RF supply (LNA and PA) Differential (with RF_TX_ALT_N) transmitter output (optional) Differential (with RF_TX_ALT_P) transmitter output (optional) 1.8V IF supply (mixers and filters) Bias setting resistor Analog pad supply (1.8V) Logic-level control for external RX/TX switch The SN260 baseband controls TX_ACTIVE and drives it high (1.8V) when in TX mode. (Refer to Table 6 and section TX_ACTIVE signal.) Description
6/88
VDD_PAD S
M IS O
SN260 Table 1.
Pin # 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
Pin assignment Pin descriptions (continued)
Signal nRESET VREG_OUT VDD_PADS VDD_CORE nSSEL_INT RES MOSI MISO VDD_PADS SCLK nSSEL PTI_EN PTI_DATA VDD_PADS RES nHOST_INT SIF_CLK SIF_MISO SIF_MOSI nSIF_LOAD GND VDD_FLASH SDBG LINK_ACTIVITY nWAKE VDD_CORE VDD_SYNTH_PRE OSCB OSCA VDD_24MHZ GND O I O I I/O Power Power O O I Power Power I/O I/O Power Ground I O Power I I O O Power Direction I Power Power Power I Description Active low chip reset (internal pull-up) Regulator output (1.8V) Pads supply (2.1 - 3.6V) 1.8V digital core supply SPI Slave Select Interrupt (from Host to SN260) This signal must be connected to nSSEL (Pin 21) Reserved for future use, do not connect to any signal. SPI Data, Master Out / Slave In (from Host to SN260) SPI Data, Master In / Slave Out (from SN260 to Host) Pads supply (2.1 - 3.6V) SPI Clock (from Host to SN260) SPI Slave Select (from Host to SN260) Frame signal of Packet Trace Interface (PTI) Data signal of Packet Trace Interface (PTI) Pads supply (2.1 - 3.6V) Reserved for future use, do not connect to any signal. Host Interrupt signal (from SN260 to Host) Serial Interface, Clock (internal pull down) Serial Interface, Master In / Slave Out Serial Interface, Master Out / Slave In Serial Interface, load strobe (open collector with internal pull up) Ground Supply 1.8V Flash memory supply Spare Debug signal Link and Activity signal Wake Interrupt signal (from Host to SN260) 1.8V digital core supply 1.8V synthesizer and pre-scalar supply 24MHz crystal oscillator or left open for when using an external clock input on OSCA 24MHz crystal oscillator or external clock input 1.8V high-frequency oscillator supply Ground supply pad in the bottom center of the package forms Pin 41 (see the EM260 Reference Design for PCB considerations)
7/88
Top-level functional description
SN260
3
Top-level functional description
Figure 2 shows a detailed block diagram of the SN260. Figure 2. SN260 block diagram
TX_ACTIVE
PA select
RF_TX_ALT_P,N
PA SYNTH PA DAC MAC + Baseband
PacketTrace
RF_P,N BIAS_R OSCA
LNA Bias
IF
ADC
Network Processor (XAP2b)
Encryption acclerator HF OSC
Network Processor Peripherals Integrated Flash and RAM
OSCB
Internal RC-OSC Serial Controller Interrupt Controller
Always powered Sleep timer
POR
nRESET SIF_CLK
VREG_OUT
Regulator Chip manager
Watchdog SIF
SIF_MISO SIF_MOSI nSIF_LOAD
IO Controller
nSSEL_INT
MISO
nSSEL
SCLK
MOSI
nWAKE
nHOST_INT
The radio receiver is a low-IF, super-heterodyne receiver. It utilizes differential signal paths to minimize noise interference, and its architecture has been chosen to optimize coexistence with other devices within the 2.4GHz band (namely, IEEE 802.11g and Bluetooth). After amplification and mixing, the signal is filtered and combined prior to being sampled by an ADC. The digital receiver implements a coherent demodulator to generate a chip stream for the hardware-based MAC. In addition, the digital receiver contains the analog radio calibration routines and control of the gain within the receiver path. The radio transmitter utilizes an efficient architecture in which the data stream directly modulates the VCO. An integrated PA boosts the output power. The calibration of the TX path as well as the output power is controlled by digital logic. If the SN260 is to be used with an external PA, the TX_ACTIVE signal should be used to control the timing of the external switching logic. The integrated 4.8GHz VCO and loop filter minimize off-chip circuitry. Only a 24MHz crystal with its loading capacitors is required to properly establish the PLL reference signal. The MAC interfaces the data memory to the RX and TX baseband modules. The MAC provides hardware-based IEEE 802.15.4 packet-level filtering. It supplies an accurate symbol time base that minimizes the synchronization effort of the software stack and meets the protocol timing requirements. In addition, it provides timer and synchronization assistance for the IEEE 802.15.4 CSMA-CA algorithm.
8/88
LINK_ACTIVITY
PTI_DATA
PTI_EN
SDBG
SN260
Top-level functional description The SN260 integrates hardware support for a Packet Trace module, which allows robust packet-based debug. This element is a critical component of InSight Desktop, the Ember software IDE, providing advanced network debug capability when coupled with the InSight Adapter. The SN260 integrates a 16-bit XAP2b microprocessor developed by Cambridge Consultants Ltd. This power-efficient, industry-proven core provides the appropriate level of processing power to meet the needs of the EmberZNet Zigbee-compliant stack, EmberZNet. In addition, the SIF module provides a non-intrusive programming and debug interface allowing for real-time application debugging. The SN260 exposes the EmberZNet Serial API over the SPI, which allows application development to occur on a Host micro controller of choice. In addition to the four SPI signals, two additional signals, nHOST_INT and nWAKE, provide an easy-to-use handshake mechanism between the Host and the SN260. The integrated voltage regulator generates a regulated 1.8V reference voltage from an unregulated supply voltage. This voltage is decoupled and routed externally to supply the 1.8V to the core logic. In addition, an integrated POR module allows for the proper cold start of the SN260. The SN260 contains one high-frequency (24MHz) crystal oscillator and, for low-power operation, a second low-frequency internal 10 kHz oscillator. The SN260 contains two power domains. The always-powered high voltage supply is used for powering the GPIO pads and critical chip functions. The rest of the chip is powered by a regulated Low Voltage Supply which can be disabled during deep sleep to reduce the power consumption.
9/88
Electrical characteristics
SN260
4
4.1
Table 2.
Electrical characteristics
Absolute maximum ratings
Table 2 lists the absolute maximum ratings for the SN260. Absolute maximum ratings
Parameter Test conditions Min. - 0.3 - 0.3 - 0.3 Max. 3.6 2.0 3.6 Unit V V V
Regulator voltage (VDD_PADS) Core voltage (VDD_24MHZ, VDD_VCO, VDD_RF, VDD_IF, VDD_PADSA, VDD_FLASH, VDD_SYNTH_PRE, VDD_CORE) Voltage on RF_P,N; RF_TX_ALT_P,N Voltage on nSSEL_INT, MOSI, MISO, SCLK, nSSEL, PTI_EN, PTI_DATA, nHOST_INT, SIF_CLK, SIF_MISO, SIF_MOSI, nSIF_LOAD, SDBG, LINK_ACTIVITY, nWAKE, nRESET, VREG_OUT Voltage on TX_ACTIVE, BIAS_R, OSCA, OSCB Storage temperature
- 0.3
VDD_PADS+0.3
V
- 0.3 - 40
VDD_CORE+0.3 + 140
V C
4.2
Table 3.
Recommended operating conditions
Table 3 lists the rated operating conditions of the SN260. Operating conditions
Parameter Test conditions Min. 2.1 1.7 - 40 1.8 Typ. Max. 3.6 1.9 + 85 Unit V V C
Regulator input voltage (VDD_PADS) Core input voltage (VDD_24MHZ, VDD_VCO, VDD_RF, VDD_IF, VDD_PADSA, VDD_FLASH, VDD_SYNTH_PRE, VDD_CORE) Temperature range
10/88
SN260
Electrical characteristics
4.3
Table 4.
Environmental characteristics
Table 4 lists the environmental characteristics of the SN260. Environmental characteristics
Parameter Test Conditions On any pin Non-RF pins RF pins Min. -2 - 400 - 225 TBD Typ. Max. +2 + 400 + 225 Unit kV V V
ESD (human body model) ESD (charged device model) ESD (charged device model) MSL (moisture sensitivity level)
4.4
Table 5.
DC electrical characteristics
Table 5 lists the DC electrical characteristics of the SN260. DC characteristics
Parameter Test Conditions Min. 2.1 Regulator output or external input 1.7 1.8 Typ. Max. 3.6 1.9 Unit V V
Regulator input voltage (VDD_PADS) Power supply range (VDD_CORE) Deep sleep current Quiescent current, including internal RC oscillator RX current Radio receiver, MAC, and baseband (boost mode) Radio receiver, MAC, and baseband CPU, RAM, and Flash memory Total RX current ( = IRadio receiver, MAC and baseband, CPU + IRAM, and Flash memory ) TX current Radio transmitter, MAC, and baseband (boost mode) Radio transmitter, MAC, and baseband At max. TX power (+ 5dBm typical) At max. TX power (+ 3dBm typical) At 0dBm typical At min. TX power (- 32dBm typical) CPU, RAM, and Flash memory At 25 C, VDD_PADS = 3.0V At 25 C and 1.8V core At 25 C, VDD_PADS = 3.0V At 25 C
1.0
A
29.0 27.0 8.5 35.5
mA mA mA mA
33.0 27.0 24.3 19.5 8.5 35.5
mA mA mA mA mA mA
Total TX current At 25 C and 1.8V core; max. ( = IRadio transmitter, MAC and baseband, CPU + power out IRAM, and Flash memory )
11/88
Electrical characteristics
SN260
4.5
Digital I/O specifications
Table 6 contains the digital I/O specifications for the SN260. The digital I/O power (named VDD_PADS) comes from three dedicated pins (pins 13, 19, and 24). The voltage applied to these pins sets the I/O voltage.
Table 6.
Digital I/O specifications
Parameter Name VDD_PADS VIL VIH IIL IIH RIPU RIPD VOL VOH IOHS IOLS IOHH IOLH IOH + IOL 0.2 x VDD_CORE 0.18 x VDD_CORE 0 0.82 x VDD_PADS 30 30 0.18 x VDD_PADS VDD_PADS 4 4 8 8 40 0.8 x VDD_PADS 0.82 x VDD_CORE 1 Min. 2.1 0 0.8 x VDD_PADS Typ. Max. 3.6 0.2 x VDD_PADS VDD_PADS -0.5 0.5 Unit V V V A A k k V V mA mA mA mA mA V V mA
Voltage supply Input voltage for logic 0 Input voltage for logic 1 Input current for logic 0 Input current for logic 1 Input pull-up resistor value Input pull-down resistor value Output voltage for logic 0 Output voltage for logic 1 Output source current (standard current pad) Output sink current (standard current pad) Output source current (high current pad: pins 33, 34, and 35) Output sink current (high current pad: pins 33, 34, and 35) Total output current (for I/O pads) Input voltage threshold for OSCA Output voltage level (TX_ACTIVE) Output source current (TX_ACTIVE)
12/88
SN260
Electrical characteristics
4.6
4.6.1
Note:
RF electrical characteristics
Receive
Table 7 lists the key parameters of the integrated IEEE 802.15.4 receiver on the SN260. Receive measurements were collected with Ember's EM260 reference design at 2440MHz. The Typical number indicates one standard deviation above the mean. Receive characteristics
Parameter Test conditions Min. 2400 1% PER, 20byte packet defined by IEEE 802.15.4 1% PER, 20byte packet defined by IEEE 802.15.4 IEEE 802.15.4 signal at -82dBm IEEE 802.15.4 signal at - 82dBm IEEE 802.15.4 signal at - 82dBm IEEE 802.15.4 signal at - 82dBm IEEE 802.15.4 signal at - 82dBm - 93 - 92 - 98.5 - 97.5 35 35 40 40 40 40 0 30 IEEE 802.15.4 signal at - 82dBm - 120 - 120 40 -6 + 120 + 120 Typ. Max. 2500 Unit MHz dBm dBm dB dB dB dB dB dB dBm dB dBc ppm ppm dB
Table 7.
Frequency range Sensitivity (boost mode) Sensitivity High-side adjacent channel rejection Low-side adjacent channel rejection 2
nd
high-side adjacent channel rejection
2nd low-side adjacent channel rejection Channel rejection for all other channels
802.11g rejection centered at + 12MHz or IEEE 802.15.4 signal at - 82dBm - 13MHz Maximum input signal level for correct operation (low gain) Image suppression Co-channel rejection Relative frequency error (2 x 40 ppm required by IEEE 802.15.4) Relative timing error (2 x 40 ppm required by IEEE 802.15.4) Linear RSSI range
13/88
Electrical characteristics
SN260
4.6.2
Note:
Transmit
Table 8 lists the key parameters of the integrated IEEE 802.15.4 transmitter on the SN260. Transmit measurements were collected with Ember's EM260 reference design at 2440MHz. The Typical number indicates one standard deviation below the mean. Transmit characteristics
Parameter Test conditions At highest power setting At highest power setting At lowest power setting As defined by IEEE 802.15.4, which sets a 35% maximum - 40 200 3.5MHz away 3.5MHz away - 20 - 30 dB dBm 0 Min. Typ. 5 3 - 32 15 25 + 40 Max. Unit dBm dBm dBm % ppm
Table 8.
Maximum output power (boost mode) Maximum output power Minimum output power Error vector magnitude Carrier frequency error Load impedance PSD mask relative PSD mask absolute
4.6.3
Synthesizer
Table 9 lists the key parameters of the integrated synthesizer on the SN260.
Table 9.
Parameter
Synthesizer characteristics
Test conditions Min. 2400 11.7 From off, with correct VCO DAC setting Channel change or RX/TX turnaround (IEEE 802.15.4 defines 192s turnaround time) - 71 - 91 - 103 - 111 100 100 Typ. Max. 2500 Unit MHz kHz s s dBc/Hz dBc/Hz dBc/Hz dBc/Hz
Frequency range Frequency resolution Lock time Relock time Phase noise at 100kHz Phase noise at 1MHz Phase noise at 4MHz Phase noise at 10MHz
14/88
SN260
Functional description
5
Functional description
The SN260 connects to the Host micro controller through a standard SPI interface. The EmberZNet Serial Protocol (EZSP) has been defined to allow an application to be written on a host micro controller of choice. Therefore, the SN260 comes with a license to EmberZNet, the EmberZNet ZigBee-compliant software stack. The following brief description of the hardware modules provides the necessary background on the operation of the SN260. For more information, contact your local ST sales representative.
5.1
Receive (RX) path
The SN260 RX path spans the analog and digital domains. The RX architecture is based on a low-IF, super-heterodyne receiver. It utilizes differential signal paths to minimize noise interference. The input RF signal is mixed down to the IF frequency of 4MHz by I and Q mixers. The output of the mixers is filtered and combined prior to being sampled by a 12Msps ADC. The RX filtering within the RX path has been designed to optimize the coexistence of the SN260 with other 2.4GHz transceivers, such as the IEEE 802.11g and Bluetooth.
5.1.1
RX baseband
The SN260 RX baseband (within the digital domain) implements a coherent demodulator for optimal performance. The baseband demodulates the O-QPSK signal at the chip level and synchronizes with the IEEE 802.15.4-2003 preamble. Once a packet preamble is detected, it de-spreads the demodulated data into 4-bit symbols. These symbols are buffered and passed to the hardware-based MAC module for filtering. In addition, the RX baseband provides the calibration and control interface to the analog RX modules, including the LNA, RX Baseband Filter, and modulation modules. The EmberZNet software includes calibration algorithms which use this interface to reduce the effects of process and temperature variation.
5.1.2
RSSI and CCA
The SN260 calculates the RSSI over an 8-symbol period as well as at the end of a received packet. It utilizes the RX gain settings and the output level of the ADC within its algorithm. The SN260 RX baseband provides support for the IEEE 802.15.4-2003 required CCA methods summarized in Table 10. Modes 1, 2, and 3 are defined by the 802.15.4-2003 standard; Mode 0 is a proprietary mode. Table 10.
CCA mode 0 1 2 3
CCA mode behavior
Mode behavior Clear channel reports busy medium if either carrier sense OR RSSI exceeds their thresholds. Clear channel reports busy medium if RSSI exceeds its threshold. Clear channel reports busy medium if carrier sense exceeds its threshold. Clear channel reports busy medium if both RSSI and carrier sense exceed their thresholds.
15/88
Functional description
SN260
5.2
Transmit (TX) path
The SN260 transmitter utilizes both analog circuitry and digital logic to produce the O-QPSK modulated signal. The area-efficient TX architecture directly modulates the spread symbols prior to transmission. The differential signal paths increase noise immunity and provide a common interface for the external balun.
5.2.1
TX baseband
The SN260 TX baseband (within the digital domain) performs the spreading of the 4-bit symbol into its IEEE 802.15.4-2003-defined 32-chip I and Q sequence. In addition, it provides the interface for software to perform the calibration of the TX module in order to reduce process, temperature, and voltage variations.
5.2.2
TX_ACTIVE signal
Even though the SN260 provides an output power suitable for most ZigBee applications, some applications will require an external power amplifier (PA). Due to the timing requirements of IEEE 802.15.4-2003, the SN250 provides a signal, TX_ACTIVE, to be used for external PA power management and RF Switching logic. When in TX, the TX Baseband drives TX_ACTIVE high (as described inTable 6). When in RX, the TX_ACTIVE signal is low. If an external PA is not required, then the TX_ACTIVE signal should be connected to GND through a 100k Ohm resistor, as shown in the application circuit in Figure 12.
5.3
Integrated MAC module
The SN260 integrates critical portions of the IEEE 802.15.4-2003 MAC requirements in hardware. This allows the SN260 to provide greater bandwidth to application and network operations. In addition, the hardware acts as a first-line filter for non-intended packets. The SN260 MAC utilizes a DMA interface to RAM memory to further reduce the overall micro controller interaction when transmitting or receiving packets. When a packet is ready for transmission, the software configures the TX MAC DMA by indicating the packet buffer RAM location. The MAC waits for the backoff period, then transitions the baseband to TX mode and performs channel assessment. When the channel is clear, the MAC reads data from the RAM buffer, calculates the CRC, and provides 4-bit symbols to the baseband. When the final byte has been read and sent to the baseband, the CRC remainder is read and transmitted. The MAC resides in RX mode most of the time, and different format and address filters keep non-intended packets from using excessive RAM buffers, as well as preventing the SN260 CPU from being interrupted. When the reception of a packet begins, the MAC reads 4-bit symbols from the baseband and calculates the CRC. It assembles the received data for storage in a RAM buffer. A RX MAC DMA provides direct access to the RAM memory. Once the packet has been received, additional data is appended to the end of the packet in the RAM buffer space. The appended data provides statistical information on the packet for the software stack.
16/88
SN260 The primary features of the MAC are:

Functional description
CRC generation, appending, and checking Hardware timers and interrupts to achieve the MAC symbol timing Automatic preamble, and SFD pre-pended to a TX packet Address recognition and packet filtering on received packets Automatic acknowledgement transmission Automatic transmission of packets from memory Automatic transmission after backoff time if channel is clear (CCA) Automatic acknowledgement checking Time stamping of received and transmitted messages Attaching packet information to received packets (LQI, RSSI, gain, time stamp, and packet status) IEEE 802.15.4-2003 timing and slotted/unslotted timing
5.4
Packet trace interface (PTI)
The SN260 integrates a true PHY-level PTI for effective network-level debugging. This twosignal interface monitors all the PHY TX and RX packets (in a non-intrusive manner) between the MAC and baseband modules. It is an asynchronous 500kbps interface and cannot be used to inject packets into the PHY/MAC interface. The two signals from the SN260 are the frame signal (PTI_EN) and the data signal (PTI_DATA). The PTI is supported by InSight Desktop.
5.5
16-bit microprocessor
The SN260 integrates the XAP2b microprocessor developed by Cambridge Consultants Ltd., making it a true network processor solution. The XAP2b is a 16-bit Harvard architecture processor with separate program and data address spaces. The word width is 16 bits for both the program and data sides. The standard XAP2 microprocessor and accompanying software tools have been enhanced to create the XAP2b microprocessor used in the SN260. The XAP2b adds data-side byte addressing support to the XAP2 allowing for more productive usage of RAM and optimized code. The XAP2b clock speed is 12MHz. When used with the EmberZNet stack, firmware is loaded into Flash memory over the air or by a serial link using a built-in bootloader in a reserved area of the Flash. Alternatively, firmware may be loaded via the SIF interface with the assistance of RAM-based utility routines also loaded via SIF.
5.6
Embedded memory
The SN260 contains embedded Flash and RAM memory for firmware storage and execution. In addition it partitions a portion of the Flash for simulated EEPROM and token storage.
17/88
Functional description
SN260
5.6.1
Simulated EEPROM
The protocol stack reserves a section of Flash memory to provide simulated EEPROM storage area for stack and customer tokens. The Flash cell has been qualified for a data retention time of >100 years at room temperature and is rated to have a guaranteed 1,000 write/erase cycles. Because the Flash cells are qualified for up to 1,000 write cycles, the simulated EEPROM implements an effective wear-leveling algorithm which effectively extends the number of write cycles for individual tokens. The number of set-token operations is finite due to the write cycle limitation of the Flash. It is not possible to guarantee an exact number of set-token operations because the life of the simulated EEPROM depends on which tokens are written and how often. The SN260 stores non-volatile information necessary for network operation as well as 8 tokens available to the Host (see section Section 7.2.6: Tokens on page 37). The majority of internal tokens are only written when the SN260 performs a network join or leave operation. As a simple estimate of possible set-token operations, consider an SN260 in a stable network (no joins or leaves) not sending any messages where the Host uses only one of the 8-byte tokens available to it. Under this scenario, a very rough estimate results in approximately 330,000 possible set-token operations. The number of possible set-token calls, though, depends on which tokens are being set, so the ratios of set-token calls for each token plays a large factor. A very rough estimate for the total number of times an App token can be set is approximately 320,000. These estimates would typically increase if the SN260 is kept closer to room temperature, since the 1,000 guaranteed write cycles of the Flash is for across temperature.
5.6.2
Flash information area (FIA)
The SN260 also includes a separate 1024-byte FIA that can be used for storage of data during manufacturing, including serial numbers and calibration values. Programming of this special Flash page can only be enabled using the SIF interface to prevent accidental corruption or erasure. The EmberZNet stack reserves a small portion of this space for its own use and in addition makes eight manufacturing tokens available to the application. See Section 7.2.6: Tokens on page 37, for more information.
5.7
Encryption accelerator
The SN260 contains a hardware AES encryption engine that is attached to the CPU using a memory-mapped interface. NIST-based CCM, CCM*, CBC-MAC, and CTR modes are implemented in hardware. These modes are described in the IEEE 802.15.4-2003 specification, with the exception of CCM*, which is described in the ZigBee Security Services Specification 1.0. The EmberZNet stack implements a security API for applications that require security at the application level.
18/88
SN260
Functional description
5.8
Reset detection
The SN260 contains multiple reset sources. The reset event is logged into the reset source register, which lets the CPU determine the cause of the last reset. The following reset causes are detected:

Power-on-reset Watchdog PC rollover Software reset Core power dip
5.9
Power-on-reset (POR)
Each voltage domain (1.8V digital core supply VDD_CORE and pads supply VDD_PADS) has a power-on-reset (POR) cell. The VDD_PADS POR cell holds the always-powered high-voltage domain in reset until the following conditions have been met:

The high-voltage pads supply VDD_PADS voltage rises above a threshold. The internal RC clock starts and generates three clock pulses. The 1.8V POR cell holds the main digital core in reset until the regulator output voltage rises above a threshold.
Additionally, the digital domain counts 1,024 clock edges on the 24MHz crystal before releasing the reset to the main digital core. Table 11 lists the features of the SN260 POR circuitry. Table 11. POR specifications
Parameter VDD_PADS POR release VDD_PADS POR assert 1.8V POR release 1.8V POR hysteresis Min. 1.0 0.5 1.35 0.08 Typ. 1.2 0.6 1.5 0.1 Max. 1.4 0.7 1.65 0.12 Unit V V V V
5.10
Clock sources
The SN260 integrates two oscillators: a high-frequency 24MHz crystal oscillator and a lowfrequency internal 10kHz RC oscillator.
5.10.1
High-frequency crystal oscillator
The integrated high-frequency crystal oscillator requires an external 24MHz crystal with an accuracy of 40ppm. Based upon the application bill of materials and current consumption requirements, the external crystal can cover a range of ESR requirements. For a lower ESR, the cost of the crystal increases but the overall current consumption decreases. Likewise, for higher ESR, the cost decreases but the current consumption increases. Therefore, the designer can choose a crystal to fit the needs of the application.
19/88
Functional description Table 12 lists the specifications for the high-frequency crystal. Table 12. High-frequency crystal specifications
Test conditions Min. Typ. 24 40 60 - 120 Initial, temperature, and aging Load capacitance of 10pF Load capacitance of 18pF - 40 + 40 100 60 1 2 Good crystal: 20 ESR, 10pF load Worst-case crystals (60, 18pF or 100, 10pF) At maximum bias 0.2 0.3 0.5 1 Max.
SN260
Parameter Frequency Duty cycle Phase noise from 1kHz to 100kHz Accuracy Crystal ESR Crystal ESR Start-up time to stable clock (max. bias) Start-up time to stable clock (optimum bias) Current consumption Current consumption Current consumption
Unit MHz % dBc/Hz ppm W W ms ms mA mA mA
5.10.2
Internal RC oscillator
The SN260 has a low-power, low-frequency RC oscillator that runs all the time. Its nominal frequency is 10kHz. It is divided down to 1kHz using a variable divider to allow software to accurately calibrate it. This calibrated clock is used by the sleep timer. Time-keeping accuracy depends on temperature fluctuations the chip is exposed to, power supply impedance, and the calibration interval, but in general it will be better than 150ppm (including crystal error of 40ppm). Table 13 lists the specifications of the RC oscillator. Table 13. RC oscillator specifications
Parameter Frequency Analog trim steps Frequency variation with supply For a voltage drop from 3.6V to 3.1V or 2.6V to 2.1V Test conditions Min. Typ. 10 1 0.75 1.5 Max. Unit kHz kHz %
20/88
SN260
Functional description
5.11
Random number generator
The SN260 allows for the generation of random numbers by exposing a randomly generated bit from the RX ADC. Analog noise current is passed through the RX path, sampled by the receive ADC, and stored in a register. The value contained in this register could be used to seed a software-generated random number. The EmberZNet stack utilizes these random numbers to seed the random MAC backoff and encryption key generators.
5.12
Watchdog timer
The SN260 contains an internal watchdog timer clocked from the internal oscillator. If the timer reaches its time-out value of approximately 2 seconds, it will reset the SN260. This reset signal cannot be routed externally to the Host. The SN260 firmware will periodically restart the watchdog timer while the firmware is running normally. The Host cannot effect or configure the watchdog timer.
5.13
Sleep timer
The 16-bit sleep timer is contained in the always-powered digital block. The clock source for the sleep timer is a calibrated 1kHz clock. The frequency is slowed down with a 2N prescaler to generate a final timer resolution of 1ms. With a 1ms tick and a 16-bit timer, the timer wraps about every 65.5 seconds. The EmberZNet stack appropriately handles timer wraps allowing the Host to order a theoretical maximum sleep delay of 4 million seconds.
5.14
Power management
The SN260 supports four different power modes: active, idle, deep sleep, and power down. Active mode is the normal, operating state of the SN260. While in idle mode, code execution halts until any interrupt occurs. All modules of the SN260 including the radio continue to operate normally. The EmberZNet stack automatically invokes idle as appropriate. Deep sleep mode and power down mode both power off most of the SN260, including the radio, and leave only the critical chip functions powered. The internal regulator is disabled and VREG_OUT is turned off. All output signals are maintained in a frozen state. Upon waking from deep sleep or power down mode, the internal regulator is re-enabled. Deep sleep and power down result in the same sleep current consumption. The two sleep modes differ as follows: the SN260 can wake on both an internal timer and an external signal from deep sleep mode; power down mode can only wake on an external signal.
21/88
SPI protocol
SN260
6
SPI protocol
The SN260 low level protocol centers on the SPI interface for communication with a pair of GPIO for handshake signaling.

The SN260 looks like a hardware peripheral. The SN260 is the slave device and all transactions are initiated by the Host (the master). The SN260 supports a reasonably high data rate.
6.1
Physical interface configuration
The SN260 supports both SPI Slave Mode 0 (clock is idle low, sample on rising edge) and SPI Slave Mode 3 (clock is idle high, sample on rising edge) at a maximum SPI clock rate of 5MHz, as illustrated in Figure 3.
Note:
The convention for the waveforms in this document is to show Mode 0. Figure 3. SPI transfer format, Mode 0 and Mode 3
The nHOST_INT signal and the nWAKE signal are both active low. The Host must supply a pull-up resistor on the nHOST_INT signal to prevent errant interruptions during undefined events such as the SN260 resetting. The SN260 supplies an internal pull-up on the nWAKE signal to prevent errant interruptions during undefined events such as the Host resetting.
6.2
SPI transaction
The basic SN260 SPI transaction is half-duplex to ensure proper framing and to give the SN260 adequate response time. The basic transaction, as shown in Figure 4, is composed of three sections: Command, Wait, and Response. The transaction can be considered analogous to a function call. The Command section is the function call, and the Response section is the return value. Figure 4. General timing diagram for a SPI transaction
22/88
SN260
SPI protocol
6.2.1
Command section
The Host begins the transaction by asserting the Slave Select and then sending a command to the SN260. This command can be of any length from 2 to 128 bytes and must not begin with 0xFF. During the Command section, the SN260 will respond with only 0xFF. The Host should ignore data on MISO during the Command section. Once the Host has completed transmission of the entire message, the transaction moves to the Wait section.
6.2.2
Wait section
The Wait section is a period of time during which the SN260 may be processing the command or performing other operations. Note that this section can be any length of time up to 200 milliseconds. Because of the variable size of the Wait section, an interrupt-driven or polling-driven method is suggested for clocking the SPI as opposed to a DMA method. Since the SN260 can require up to 200 milliseconds to respond, as long as the Host keeps Slave Select active, the Host can perform other tasks while waiting for a Response. To determine when a Response is ready, use one of two methods:

Clock the SPI until the SN260 transmits a byte other than 0xFF. Interrupt on the falling edge of nHOST_INT.
The first method, clocking the SPI, is recommended due to simplicity in implementing. During the Wait section, the SN260 will transmit only 0xFF and will ignore all incoming data until the Response is ready. When the SN260 transmits a byte other than 0xFF, the transaction has officially moved into the Response section. Therefore, the Host can poll for a Response by continuing to clock the SPI by transmitting 0xFF and waiting for the SN260 to transmit a byte other than 0xFF. The SN260 will also indicate that a Response is ready by asserting the nHOST_INT signal. The falling edge of nHOST_INT is the indication that a Response is ready. Once the nHOST_INT signal asserts, nHOST_INT will return to idle after the Host begins to clock data.
6.2.3
Response section
When the SN260 transmits a byte other than 0xFF, the transaction has officially moved into the Response section. The data format is the same format used in the Command section. The response can be of any length from 2 to 128 bytes and will not begin with 0xFF. Depending on the actual response, the length of the response is known from the first or second byte and this length should be used by the Host to clock out exactly the correct number of bytes. Once all bytes have been clocked, it is allowable for the Host to de-assert chip select. Since the Host is in control of clocking the SPI, there are no ACKs or similar signals needed back from the Host because the SN260 will assume the Host could accept the bytes being clocked on the SPI. After every transaction, the Host must hold the Slave Select high for a minimum of 1ms. This timing requirement is called the inter-command spacing and is necessary to allow the SN260 to process a command and become ready to accept a new command.
6.2.4
Asynchronous signaling
When the SN260 has data to send to the Host, it will assert the nHOST_INT signal. The nHOST_INT signal is designed to be an edge-triggered signal as opposed to a leveltriggered signal; therefore, the falling edge of nHOST_INT is the true indicator of data availability. The Host then has the responsibility to initiate a transaction to ask the SN260 for its output. The Host should initiate this transaction as soon as possible to prevent possible
23/88
SPI protocol
SN260
backup of data in the SN260. The SN260 will de-assert the nHOST_INT signal after receiving a byte on the SPI. Due to inherent latency in the SN260, the timing of when the nHOST_INT signal returns to idle can vary between transactions. nHOST_INT will always return to idle for a minimum of 10s before asserting again. If the SN260 has more output available after the transaction has completed, the nHOST_INT signal will assert again after Slave Select is de-asserted and the Host must make another request.
6.2.5
Spacing
To ensure that the SN260 is always able to deal with incoming commands, a minimum intercommand spacing is defined at 1ms. After every transaction, the Host must hold the Slave Select high for a minimum of 1ms. The Host must respect the inter-command spacing requirement, or the SN260 will not have time to operate on the command; additional commands could result in error conditions or undesired behavior. If the nHOST_INT signal is not already asserted, the Host is allowed to use the Wake handshake instead of the intercommand spacing to determine if the SN260 is ready to accept a command.
6.2.6
Waking the SN260 from sleep
Waking up the SN260 involves a simple handshaking routine as illustrated in Figure 5. This handshaking ensures that the Host will wait until the SN260 is fully awake and ready to accept commands from the Host. If the SN260 is already awake when the handshake is performed (such as when the Host resets and the SN260 is already operating), the handshake will proceed as described below with no ill effects.
Note:
A wake handshake cannot be performed if nHOST_INT is already asserted. Figure 5. SN260 wake sequence
Waking the SN260 involves the following steps: 1. 2. 3. 4. Host asserts nWAKE. SN260 interrupts on nWAKE and exits sleep. SN260 performs all operations it needs to and will not respond until it is ready to accept commands. SN260 asserts nHOST_INT within 10ms of nWAKE asserting. If the SN260 does not assert nHOST_INT within 10ms of nWAKE, it is valid for the Host to consider the SN260 unresponsive and to reset the SN260. Host detects nHOST_INT assertion. Since the assertion of nHOST_INT indicates the SN260 can accept SPI transactions, the Host does not need to hold Slave Select high for the normally required minimum 1ms of inter-command spacing. Host de-asserts nWAKE after detecting nHOST_INT assertion. SN260 will de-assert nHOST_INT within 25s of nWAKE de-asserting. After 25s, any change on nHOST_INT will be an indication of a normal asynchronous (callback) event.
5.
6. 7. 8.
24/88
SN260
SPI protocol
6.2.7
Error conditions
If two or more different error conditions occur back to back, only the first error condition will be reported to the Host (if it is possible to report the error). The following are error conditions that might occur with the SN260.
Oversized EZSP frame If the transaction includes an EZSP Frame, the Length Byte cannot be a value greater than 125. If the SN260 detects a length byte greater than 125, it will drop the incoming Command and abort the entire transaction. The SN260 will then assert nHOST_INT after Slave Select returns to Idle to inform the Host through an error code in the Response section what has happened. Not only is the Command in the problematic transaction dropped by the SN260, but the next Command is also dropped, because it is responded to with the Oversized EZSP Frame Error Response.
Aborted transaction An aborted transaction is any transaction where Slave Select returns to Idle prematurely and the SPI Protocol dropped the transaction. The most common reason for Slave Select returning to Idle prematurely is the Host unexpectedly resetting. If a transaction is aborted, the SN260 will assert nHOST_INT to inform the Host through an error code in the Response section what has happened. When a transaction is aborted, not only does the Command in the problematic transaction get dropped by the SN260, but the next Command also gets dropped since it is responded to with the Aborted Transaction Error Response.
Missing frame terminator Every Command and Response must be terminated with the Frame Terminator byte. The SN260 will drop any Command that is missing the Frame Terminator. The SN260 will then immediately provide the Missing Frame Terminator Error Response.
Long transaction A Long Transaction error occurs when the Host clocks too many bytes. As long as the inter-command spacing requirement is met, this error condition should not cause a problem, since the SN260 will send only 0xFF outside of the Response section as well as ignore incoming bytes outside of the Command section.
Unresponsive Unresponsive can mean the SN260 is not powered, not fully booted yet, incorrectly connected to the Host, or busy performing other tasks. The Host must wait the maximum length of the Wait section before it can consider the SN260 unresponsive to the Command section. This maximum length is 200 milliseconds, measured from the end of the last byte sent in the Command Section. If the SN260 ever fails to respond during the Wait section, it is valid for the Host to consider the SN260 unresponsive and to reset the SN260. Additionally, if nHOST_INT does not assert within 10ms of nWAKE asserting during the wake handshake, the Host can consider the SN260 unresponsive and reset the SN260.
6.3
SPI protocol timing
Figure 6 illustrates all critical timing parameters in the SPI Protocol. These timing parameters are a result of the SN260's internal operation and both constrain Host behavior and characterize SN260 operation. The parameters shown are discussed elsewhere in this document. Note that Figure 6 is not drawn to scale, but is provided to illustrate where the parameters are measured.
25/88
SPI protocol Figure 6. SPI protocol timing waveform
SN260
Table 14 lists the timing parameters of the SPI protocol. These parameters are illustrated in Figure 6. Table 14.
Parameter t1 (a) t1 (b) t2 t3 t4 t5 t6 t7 t8 t9 t10
SPI protocol timing parameters
Description Wake handshake, while 260 is awake Wake handshake, while 260 is asleep Wake handshake finish Reset pulse width Startup time nHOST_INT de-asserting after Command Clock rate Wait section nHOST_INT de-asserting after Response nHOST_INT asserting after transaction Inter-command spacing 13 200 25 20 25 1 755 130 70 200000 800 800 1.1 8 250 35 1500 75 Min. Typ. 133 7.3 1.2 Max. 150 10 25 Unit s ms s s ms s ns s s s ms
6.4
Data format
The data format, also referred to as a command, is the same for both the Command section and the Response section. The data format of the SPI Protocol is straightforward, as illustrated in Figure 7.
Figure 7.
SPI protocol data format
The total length of a command must not exceed 128 bytes. All commands must begin with the SPI Byte. Some commands are only two bytes--that is, they contain the SPI Byte and Frame Terminator only.
26/88
SN260
SPI protocol The Length Byte is only included if there is information in the EZSP Frame (EmberZNet Serial Protocol Frame) and the Length Byte defines the length of just the EZSP Frame. Therefore, if a command includes an EZSP Frame, the Length Byte can have a value from 2 through 125 and the overall command size will be 5 through 128 bytes. The SPI Byte can be a specific value indicating if there is an EZSP Frame or not, and if there is an EZSP Frame, then the Length Byte can be expected. The Error Byte is used by the error responses to provide additional information about the error and appears in place of the length byte. This additional information is described in the following sections. The EZSP Frame contains the data needed for operating EmberZNet. The EZSP Frame and its format are explained in Section 7: EmberZNet serial protocol on page 34. The Frame Terminator is a special control byte used to mark the end of a command. The Frame Terminator byte is defined as 0xA7 and is appended to all Commands and Responses immediately after the final data byte. The purpose of the Frame Terminator is to provide a known byte the SPI Protocol can use to detect a corrupt command. For example, if the SN260 resets during the Response Section, the Host will still clock out the correct number of bytes. But when the host attempts to verify the value 0xA7 at the end of the Response, it will see either the value 0x00 or 0xFF and know that the SN260 just reset and the corrupt Response should be discarded.
Note:
The Length Byte only specifies the length of the EZSP Frame. It does not include the Frame Terminator.
6.5
Table 15.
Command value Any Any Any
SPI byte
Table 15 lists the possible commands and their responses in the SPI Byte. SPI commands & responses
Command Any Any Any Response value 0x00 0x01 0x02 Response SN260 reset occurred--This is never used in another response; it always indicates an SN260 Reset. Oversized EZSP Frame received--This is never used in another response; it always indicates an overflow occurred. Aborted Transaction occurred--This is never used in another response; it always indicates an aborted transaction occurred. Missing Frame Terminator--This is never used in another response; it always indicates a missing frame terminator in the command. Reserved [none] bit[7] is always set. bit[6] is always cleared. bit[5:0] is a number from 1-63. [none] EZSP frame Invalid
Any Any 0x00 - 0x0F 0x0A 0x0B 0xF0 - 0xFD 0xFE 0xFF
Any Any Reserved SPI Protocol Version SPI Status Reserved EZSP Frame Invalid
0x03 0x04 [none] 0x81 - 0xBF
0xC0 - 0xC1 bit[7] is always set. bit[6] is always set. bit[0]--Set if Alive. [none] 0xFE 0xFF
27/88
SPI protocol
SN260
6.5.1
Primary SPI bytes
There are three primary SPI bytes: SPI protocol version, SPI status, and EZSP frame.
SPI protocol version [0x0A] Sending this command requests the SPI Protocol Version number from the SPI Interface. The response will always have bit 7 set and bit 6 cleared. In this current version, the response will be 0x81, because the version number corresponding to this set of Command-Response values is version number 1. The version number can be a value from 1 to 63 (0x81-0xBF).
SPI status [0x0B] Sending this command asks for the SN260 status. The response status byte will always have the upper 2 bits set. In this current version, the status byte only has one status bit [0], which is set if the SN260 is alive and ready for commands.
EZSP frame [0xFE] This byte indicates that the current transaction is an EZSP transaction and there is more data to follow. This SPI Byte, and only this SPI Byte, will cause the transaction to look like the full data format illustrated in Figure 7. The byte immediately after this SPI Byte will be a Length Byte, and it is used to identify the length of the EZSP Frame. The EZSP Frame is defined in section Section 7: EmberZNet serial protocol on page 34. If the SPI Byte is 0xFE, it means the minimum transaction size is five bytes. All other SPI Bytes mean the transaction size is two or three bytes.
6.5.2
Special response bytes
There are only five SPI Byte values, 0x00-0x04, ever used as error codes (see Table 16). When the error condition occurs, any command sent to the SN260 will be ignored and responded to with one of these codes. These special SPI Bytes must be trapped and dealt with. In addition, for each error condition the Error Byte (instead of the Length Byte) is also sent with the SPI Byte.
Table 16.
SPI byte value 0x00
Byte values used as error codes
Error message Error description See Section 6.6: Powering on, power cycling, and rebooting. The command contained an EZSP frame with a Length Byte greater than 125. The SN260 was forced to drop the entire command. The transaction was not completed properly and the SN260 was forced to abort the transaction. Error byte description The reset type. Refer to the API documentation discussing EmberResetType. Reserved
SN260 Reset
0x01
Oversized EZSP Frame Aborted Transaction Missing Frame Terminator Reserved
0x02
Reserved
0x03 0x04
The command was missing the Frame Terminator. The SN260 was forced to drop the Reserved entire command. [none] [none]
28/88
SN260
SPI protocol
6.6
Powering on, power cycling, and rebooting
When the Host powers on (or reboots), it cannot guarantee that the SN260 is awake and ready to receive commands. Therefore, the Host should always perform the Wake SN260 handshake to guarantee that the SN260 is awake. If the SN260 resets, it needs to inform the Host so that the Host can reconfigure the stack if needed. When the SN260 resets, it will assert the nHOST_INT signal, telling the Host that it has data. The Host should request data from the SN260 as usual. The SN260 will ignore whatever command is sent to it and respond only with two bytes. The first byte will always be 0x00 and the second byte will be the reset type as defined by EmberResetType. This specialty SPI Byte is never used in another Response SPI Byte. If the Host sees 0x00 from the SN260, it knows that the SN260 has been reset. The SN260 will de-assert the nHOST_INT signal shortly after receiving a byte on the SPI and process all further commands in the usual manner. In addition to the Host having control of the reset line of the SN260, the EmberZNet Serial Protocol also provides a mechanism for a software reboot.
6.6.1
Unexpected resets
The SN260 is designed to protect itself against undefined behavior due to unexpected resets. The protection is based on the state of Slave Select since the inter-command spacing mandates that Slave Select must return to idle. The SN260's internal SPI Protocol uses Slave Select returning to idle as a trigger to re-initialize its SPI Protocol. By always reinitializing, the SN260 is protected against the Host unexpectedly resetting or terminating a transaction. Additionally, if Slave Select is active when the SN260 powers on, the SN260 will ignore SPI data until Slave Select returns to idle. By ignoring SPI traffic until idle, the SN260 will not begin receiving in the middle of a transaction. If the Host resets, in most cases it should reset the SN260 as well so that both devices are once again in the same state: freshly booted. Alternately, the Host can attempt to recover from the reset by recovering its previous state and resynchronizing with the state of the SN260. If the SN260 resets during a transaction, the Host can expect either a Wait Section timeout or a missing Frame Terminator indicating an invalid Response. If the SN260 resets outside of a transaction, the Host should proceed normally.
6.7
Transaction examples
This section contains the following transaction examples:

SPI protocol version EmberZNet serial protocol frame -- NOP command SN260 reset Three-part transaction: Wake, Get Version, Stack Status Callback
29/88
SPI protocol
SN260
6.7.1
SPI protocol version
Figure 8. SPI protocol version example
1. 2. 3. 4. 5. 6. 7. 8.
Activate Slave Select (nSSEL). Transmit the command 0x0A - SPI Protocol Version Request. Transmit the Frame Terminator, 0xA7. Wait for nHOST_INT to assert. Transmit and receive 0xFF until a byte other than 0xFF is received. Receive response 0x81 (a byte other than 0xFF), then receive the Frame Terminator, 0xA7. Bit 7 is always set and bit 6 is always cleared in the Version Response, so this is Version 1. De-activate Slave Select.
6.7.2
EmberZNet serial protocol frame -- NOP command
Figure 9. EmberZNet serial protocol frame - NOP command example
1. 2.
Activate Slave Select (nSSEL). Transmit the appropriate command: - - - - - 0xFE: SPI Byte indicating an EZSP Frame 0x02: Length Byte showing the EZSP Frame is 2 bytes long 0x00: EZSP Frame Control Byte indicating a command with no sleeping 0x05: EZSP Frame Type Byte indicating the NOP command 0xA7: Frame Terminator
3. 4. 5.
Wait for nHOST_INT to assert. Transmit and receive 0xFF until a byte other than 0xFF is received. Receive response 0xFE (a byte other than 0xFF) and read the next byte for a length.
30/88
SN260 6. 7.
SPI protocol Stop transmitting after the number of bytes (length) is received plus the Frame Terminator. Decode the response: - - - - - 8. 0xFE: SPI Byte indicating an EZSP Frame 0x02: Length Byte showing the EZSP Frame is 2 bytes long 0x80: EZSP Frame Control Byte indicating a response with no overflow 0x05: EZSP Frame Type Byte indicating the NOP response 0xA7: Frame Terminator
De-activate Slave Select.
6.7.3
SN260 reset
Figure 10. SN260 reset example
1. 2. 3.
nHOST_INT asserts. Activate Slave Select (nSSEL). Transmit the command: - - - - - 0xFE: SPI Byte indicating an EZSP Frame 0x02: Length Byte showing the EZSP Frame is 2 bytes long 0x00: EZSP Frame Control Byte indicating a command with no sleeping 0x06: EZSP Frame Type Byte indicating the callback command 0xA7: Frame Terminator
4. 5. 6. 7. 8. 9.
Wait for nHOST_INT to assert. Transmit and receive 0xFF until a byte other than 0xFF is received. Receive response 0x00 (a byte other than 0xFF). Receive the Error Byte and decode (0x02 is enumerated as RESET_POWERON). Receive the Frame Terminator (0xA7). Response 0x00 indicates the SN260 has reset and the Host should respond appropriately.
10. Deactivate Slave Select. 11. Since nHOST_INT does not assert again, there is no more data for the Host.
31/88
SPI protocol
SN260
6.7.4
Three-part transaction: Wake, Get Version, Stack Status Callback
Figure 11. Timing diagram of the three-part transaction
1. 2. 3. 4. 5. 6. 7. 8. 9.
Activate nWAKE and activate timeout timer. SN260 wakes up (if not already) awake and enables communication. nHOST_INT asserts, indicating the SN260 can accept commands. Host sees nHOST_INT activation within 10ms and deactivates nWAKE and timeout timer. nHOST_INT de-asserts immediately after nWAKE. Activate Slave Select. Transmit the Command 0x0A - SPI Protocol Version Request. Transmit the Frame Terminator, 0xA7. Wait for nHOST_INT to assert.
10. Transmit and receive 0xFF until a byte other than 0xFF is received. 11. Receive response 0x81 (a byte other than 0xFF), then receive the Frame Terminator, 0xA7. 12. Bit 7 is always set and bit 6 is always cleared in the Version Response, so this is Version 1. 13. Deactivate Slave Select. 14. Host begins timing the inter-command spacing of 1ms in preparation for sending the next command. 15. nHOST_INT asserts shortly after deactivating Slave Select, indicating a callback. 16. Host sees nHOST_INT, but waits for the 1ms before responding. 17. Activate Slave Select. 18. Transmit the command: - - - - - 0xFE: SPI Byte indicating an EZSP Frame 0x02: Length Byte showing the EZSP Frame is 2 bytes long 0x00: EZSP Frame Control Byte indicating a command with no sleeping 0x06: EZSP Frame Type Byte indicating the callback command 0xA7: Frame Terminator
19. Wait for nHOST_INT to assert. 20. Transmit and receive 0xFF until a byte other than 0xFF is received. 21. Receive response 0xFE (a byte other than 0xFF), read the next byte for a length. 22. Stop transmitting after the number of bytes (length) is received plus the Frame Terminator.
32/88
SN260 23. Decode the response: - - - - - - 0xFE: SPI Byte indicating an EZSP Frame 0x03: Length Byte showing the EZSP Frame is 3 bytes long
SPI protocol
0x80: EZSP Frame Control Byte indicating a response with no overflow 0x19: EZSP Frame Type Byte indicating the emberStackStatusHandler command 0x91: EmberStatus EMBER_NETWORK_DOWN from emberStackStatusHandler 0xA7 - Frame Terminator
24. Deactivate Slave Select. 25. Since nHOST_INT does not assert again, there is no more data for the Host.
33/88
EmberZNet serial protocol
SN260
7
EmberZNet serial protocol
EmberZnet Serial Protocol (EZSP)has been designed to be very familiarr to customers who have used the EmberZNet 2.x stack API. The majority of the commands and responses are functionally identical to those found in EmberZNet 2.x. The variations are due mainly to the timing differences of running the application on a separate processor across a serial interface. Communication between the SN260 and the Host consists of a two-message transaction. The Host sends a command message to the SN260 and then the SN260 sends a response message to the Host. If the SN260 needs to communicate asynchronously with the Host, it will indicate this by using the interrupt line and then waiting for the Host to send the callback command. All EZSP frames begin with a Frame Control Byte followed by a Frame ID Byte. The format of the rest of the frame depends on the frame ID. Section 7.3: Protocol format on page 38 defines the format for all the frame IDs. Most of the frames have a fixed length. A few, such as those containing application messages, are of variable length. The frame control indicates the direction of the message (command or response). For commands, the frame control also contains power management information, and for responses it also contains status information. When a command contains an application message, the Host must supply a one-byte tag. This tag is used in future commands and responses to refer to the message. For example, when sending a message, the Host provides both the message contents and a tag. The tag is then used to report the fate of the message in a later response from the SN260.
7.1
Byte order
All multiple octet fields are transmitted and received with the least significant octet first, also referred to as little endian. This is the same byte order convention specified by 802.15.4 and ZigBee. Note that EUI64 fields are treated as a 64-bit number and are therefore transmitted and received in little endian order. Each individual octet is transmitted with the most significant bit first, as shown in Section 6.1: Physical interface configuration on page 22.
7.2
Conceptual overview
This section provides an overview of the concepts that are specific to the SN260 or that differ from the EmberZNet 2.x stack API. The commands and responses mentioned in this overview are described in more detail later in this document.
7.2.1
Stack configuration
The Host can use the version command to obtain information about the firmware running on the SN260. There are a number of configuration values that affect the behavior of the stack. The Host can read these values at any time using the getConfigurationValue command. After the SN260 has reset, the Host can modify any of the default values using the setConfigurationValue command. The Host must then provide information about the application endpoints using the addEndpoint command. Table 17 gives the minimum, default and maximum values for each of the configuration values. Also listed is the RAM cost. This is the number of bytes of additional RAM required to increase the configuration value by one. Since the total amount of RAM is fixed, the
34/88
SN260
EmberZNet serial protocol additional RAM required must be made available by reducing one of the other configuration values.
Table 17.
Configuration values
Value Min. Def. Max. Units packet buffers 16 neighbors RAM Cost 40 Description The number of packet buffers available to the stack. The maximum number of router neighbors the stack can keep track of. A neighbor is a node within radio range. The maximum number of datagram and sequenced messages the stack can have in the process of being either transmitted or received at any given time. The maximum number of bindings supported by the stack. It includes the bindings in EEPROM and in RAM. The number of binding table entries in RAM. The number of binding table entries that can concurrently support an open sequenced connection. The maximum number of destinations to which a node can route messages. This include both messages originating at this node and those relayed for others. The number of simultaneous route discoveries that a node will support. End-device child endpoints larger than this value will not have their discovery information cached by their router parent. The size of an entry in the end device discovery cache on a router. Endpoint descriptions longer than this will not be cached. The number of entries in the discovery cache on a router. Each end device child requires 1 + (D) entries. The cache is held in EEPROM. Specifies the stack profile. The security level used for security at the MAC and network layers. The supported values are 0 (no security) and 5 (payload is encrypted and a four-byte MIC is used for authentication). The maximum number of hops for a message. The maximum number of end device children that a router will support. The maximum amount of time that the MAC will hold a message for indirect transmission to a child.
EZSP_CONFIG_PACKET_BUFFER_ COUNT EZSP_CONFIG_NEIGHBOR_TABLE_ SIZE
5
24
8
16
18
EZSP_CONFIG_TRANSPORT_ PACKET_COUNT
0
10
messages
10
EZSP_CONFIG_BINDING_ TABLE_SIZE (A) EZSP_CONFIG_TEMPORARY_ BINDING_ENTRIES (B) EZSP_CONFIG_TRANSPORT_ CONNECTION_COUNT
0
8
32 + (B) (A)
entries
3
0
8
entries
12
0
0
entries
12
EZSP_CONFIG_ROUTE_ TABLE_SIZE (C) EZSP_CONFIG_DISCOVERY_ TABLE_SIZE EZSP_CONFIG_DISCOVERY_ CACHE_ENDPOINTS (D)
0
16
entries
6
0
8
entries
10
0
4
endpoints
0
EZSP_CONFIG_DISCOVERY_ CACHE_ENTRY_SIZE
11 + (D)
15
15
bytes
0
EZSP_CONFIG_DISCOVERY_ CACHE_SIZE EZSP_CONFIG_STACK_PROFILE
0 0
35 0
35
entries
0 0
EZSP_CONFIG_SECURITY_LEVEL
0
5
5
0
EZSP_CONFIG_MAX_HOPS EZSP_CONFIG_MAX_END_DEVICE_ CHILDREN (E) EZSP_CONFIG_INDIRECT_ TRANSMISSION_TIMEOUT
0 0
10 6 32
hops children milliseconds
0 4
0
3000 30000
0
35/88
EmberZNet serial protocol
Table 17. Configuration values (continued)
Value Min. Def. Max. Units RAM Cost Description
SN260
EZSP_CONFIG_RESERVED_ ROUTING_ENTRIES
0
0
(C)
entries
0
The number of route table entries that are reserved for temporary aggregation routes in the mesh stack. The maximum amount of time that a mobile node can wait between polls. If no poll is heard within this timeout, then the parent removes the mobile node from its tables. The number of child table entries reserved for use only by mobile nodes. The amount of RAM available for use by the Host. Enables boost power mode and/or the alternate transmitter output.
EZSP_CONFIG_MOBILE_NODE_ POLL_TIMEOUT EZSP_CONFIG_RESERVED_ MOBILE_CHILD_ENTRIES EZSP_CONFIG_HOST_RAM EZSP_CONFIG_TX_POWER_MODE
0
20
quarter seconds
0
0 0 0
0 0 0
(E) 255 3
entries bytes
0 1 0
7.2.2
Policy settings
There are some situations when the SN260 must make a decision but there isn't enough time to consult with the Host. The Host can control what decision is made by setting the policy in advance. The SN260 will then make decisions according to the current policy. The Host is informed via callbacks each time a decision is made, but by the time the news reaches the Host, it is too late to change that decision. You can change the policies at any time by using the setPolicy command. A policy is used for trust center behavior, external binding modification requests, datagram replies, generating pollHandler callbacks, and the contents of the unicastSent and messageSent callbacks.
7.2.3
Datagram replies
The policy for datagram replies allows the Host to decide whether it wants to supply the SN260 with a reply payload for every datagram received. If the Host sets the policy to not supply a reply, the SN260 will automatically send an empty reply (containing no payload) for every datagram received. If the Host sets the policy to supply the reply, then the SN260 will only send a reply when instructed by the Host. If the reply does not reach the sender before the transport retry timeout expires, the sender will transmit the datagram again. The Host must process the incoming message and supply the reply quickly enough to avoid retransmission by the sender. Provided this timing constraint is met, multiple datagrams can be received before the first reply is supplied and the replies can be supplied in any order.
7.2.4
Callbacks
Asynchronous callbacks from the SN260 are sent to the Host as the response to a callback command. The SN260 uses the interrupt line to indicate that the Host should send a callback command. The SN260 will queue multiple callbacks while it waits for the Host, and each response only delivers one callback. If the SN260 receives the callback command when there are no pending callbacks, it will reply with the noCallbacks response.
36/88
SN260
EmberZNet serial protocol
7.2.5
Power management
The SN260 will always idle its processor whenever possible. To further reduce power consumption, the SN260 can be put to sleep by the Host. In power down mode, only an external interrupt will wake the SN260. In deep sleep mode, the SN260 will use its internal timer to wake up for scheduled events. The SN260 provides two independent timers that the Host can use for any purpose, including waking up the SN260 from deep sleep mode. Timers are set using the setTimer command and generate timerHandler callbacks. The initial frame control byte of every command tells the SN260 which sleep mode to enter after it has responded to the command. Including this information in every command (instead of having a separate power management command) allows the SN260 to be put to sleep faster. If the Host needs to put the SN260 to sleep without also performing another action, the nop command can be used. In deep sleep mode, the SN260 will wake up for an internal event. If the event does not produce a callback for the Host, the SN260 will go back to sleep once the event has been handled. If the event does produce a callback, the SN260 will signal the Host and remain awake waiting for the callback command. If the frame control byte of the callback command specifies deep sleep mode, then the SN260 would normally go back to sleep after responding with the callback. However, if there is a second callback pending, the SN260 will remain awake waiting for another callback command. To avoid disrupting the operation of the network, only put the SN260 to sleep when it is not joined to a network or when it is joined as a sleeping end device. If the SN260 is joined as a sleeping end device, then it must poll its parent in order to receive messages. The Host controls the polling behavior using the pollForData command. Polls are sent periodically with the interval set by the Host or a single poll can be sent. The result of every poll attempt is optionally reported using the pollCompleteHandler callback.
7.2.6
Tokens
Some of the non-volatile storage on the SN260 is made available for use by the Host. Up to 8 manufacturing tokens stored in the flash information area can be read using the getMfgToken command and up to 8 tokens stored in the simulated EEPROM can be read and written using the setToken and getToken commands. Each token is 8 bytes. Tokens preserve their values between reboots. Refer to section Simulated EEPROM for a description of the simulated EEPROM and write cycle estimates.
7.2.7
RAM
Some of the RAM on the SN260 can be reserved by the Host for its own use. The amount of space reserved is the EZSP_CONFIG_HOST_RAM configuration value (set using the setConfigurationValue command). The Host can then read and write data using the setRam and getRam commands. If the Host chooses to reserve RAM, this will reduce the number of messages and callbacks that the SN260 can buffer.
37/88
EmberZNet serial protocol
SN260
7.2.8
SN260 status
The frame control byte of every response sent by the SN260 contains two status bits:

The overflow bit is set if the SN260 ran out of memory at any time since the previous response was sent. If this bit is set, then messages may have been lost. The truncated bit is set if the SN260 truncated the current response. If this bit is set, the command from the Host produced a response larger than the maximum EZSP frame length.
You can use the nop command to check the status of the SN260 without also performing another action.
7.2.9
Random number generator
The Host can obtain a random number from the SN260 using the getRandomNumber command. The random number is generated from analog noise in the radio and can be used to seed a random number generator on the Host.
7.3
Protocol format
All EZSP frames begin with a frame control byte. Table 18 describes the meaning of this byte for command and response frames. Table 19 describes the sleep modes, Table 20 describes the overflow status bit and Table 21 describes the truncated status bit. The second byte of all EZSP frames is the frame ID byte. Table 18.
Bit 7 (MSB) 6 5 4 3 2 1 0 (LSB)
Frame control byte
Command 0 0 (reserved) 0 (reserved) 0 (reserved) 0 (reserved) 0 (reserved) sleepMode[1] sleepMode[0] Sleep modes sleepMode[0] 1 0 1 0 Description Reserved. Power down. Deep sleep. Idle. Response 1 0 (reserved) 0 (reserved) 0 (reserved) 0 (reserved) 0 (reserved) truncated overflow
Table 19.
sleepMode[1] 1 1 0 0
38/88
SN260 Table 20. Overflow status
Description
EmberZNet serial protocol
overflow 1 0
The SN260 ran out of memory since the previous response. No memory shortage since the previous response.
Table 21.
Truncated status
Description The SN260 truncated the current response to avoid exceeding the maximum EZSP frame length. The current response was not truncated.
truncated 1 0
Section 7.3.1: Type definitions defines all the types used by the SN260 and Section 7.3.2: Structure definitions defines all the structures. Section 7.3.3: Named values enumerates all the named values for the different types. The subsequent sections list all the frames supported by the SN260, specifying the Frame ID, the command parameters and the response parameters. The list is divided into five sections:

Section 7.3.4 lists Configuration frames. Section 7.3.5 lists Utilities frames. Section 7.3.6 lists Networking frames. Section 7.3.7 lists Binding frames. Section 7.3.8 lists Messaging frames.
Finally, section Section 7.3.9 provides an alphabetical list of all the frames.
39/88
EmberZNet serial protocol
SN260
7.3.1
Table 22.
Type definitions
Type definitions
Type Alias int8u int8u int16u int8u int8u int8u int8u int8u int8u int8u int8u int8u int8u int8u int8u int16u int16u int8u[8] True or false. Identifies a configuration value. Values for EZSP_CONFIG_TX_POWER_MODE. Return type for configuration commands. Identifies a policy. Identifies a policy decision. Return type for stack functions. Either marks an event as inactive or specifies the units for the event execution time. The type of the node. The possible join states for a node. Incoming message types. Binding types. Options to use when sending a unicast message. Network scan types. Decision made by the trust center when a node attempts to join. 16-bit ZigBee network address. 802.15.4 PAN ID. EUI 64-bit ID (an IEEE address). Description
boolean EzspConfigId EzspConfigTxPowerMode EzspConfigStatus EzspPolicyId EzspDecisionId EmberStatus EmberEventUnits EmberNodeType EmberNetworkStatus EmberIncomingMessageType EmberBindingType EmberUnicastOption EmberNetworkScanType EmberJoinDecision EmberNodeId EmberPanId EmberEUI64
40/88
SN260
EmberZNet serial protocol
7.3.2
Table 23.
Structure definitions
Structure definitions
Structure Field Description Network parameters.
EmberNetworkParameters
int16u panId int8s radioTxPower int8u radioChannel
The network's PAN identifier. A power setting, in dBm. A radio channel. ZigBee APS frame parameters.
int16u profileId EmberApsFrame int8u clusterId int8u sourceEndpoint
The application profile ID that describes the format of the message. The cluster ID for this message. The source endpoint.
int8u destinationEndpoint The destination endpoint. EmberUnicastOption options A bitmask of options. An entry in the binding table. EmberBindingType type int8u local int8u remote The type of binding. The endpoint on the local node. The endpoint on the remote node (specified by identifier). A cluster ID that matches one from the local endpoint's simple descriptor. This cluster ID is set by the provisioning application to indicate which part an endpoint's functionality is bound to this particular remote node and is used to distinguish between unicast and multicast bindings. A binding can be used to send messages with any cluster ID, not just the one listed in the binding. A 64-bit identifier. This is either the destination EUI64 (for unicasts) or the 64-bit group address (for multicasts).
EmberBindingTableEntry int8u clusterId
EmberEUI64 identifier
41/88
EmberZNet serial protocol
SN260
7.3.3
Table 24.
Named values
boolean
Structure Field 0x00 0x01 Description An alias for zero, used for clarity. An alias for one, used for clarity.
FALSE TRUE
Table 25.
EzspConfigId
Structure Field 0x01 0x02 Description The number of packet buffers available to the stack. The maximum number of router neighbors the stack can keep track of. A neighbor is a node within radio range. The maximum number of datagram and sequenced messages the stack can have 'in-flight' at any time. Here, 'in-flight' means 'in the process of being either transmitted or received'. The maximum number of bindings supported by the stack. It includes the bindings in EEPROM and in RAM. The number of binding table entries in RAM. The number of binding table entries that can concurrently support an open sequenced connection. The maximum number of destinations to which a node can route messages. This include both messages originating at this node and those relayed for others. The number of simultaneous route discoveries that a node will support. End-device child endpoints larger than this value will not have their discovery information cached by their router parent. The size of an entry in the end device discovery cache on a router. Endpoint descriptions longer than this will not be cached. The number of entries in the discovery cache on a router. Each end device child requires 1 + EZSP_CONFIG_DISCOVERY_CACHE_ENDPOINTS entries. The cache is held in EEPROM. Specifies the stack profile. The security level used for security at the MAC and network layers. The supported values are 0 (no security) and 5 (payload is encrypted and a four-byte MIC is used for authentication). The maximum number of hops for a message. The maximum number of end device children that a router will support.
EZSP_CONFIG_PACKET_BUFFER_COUNT EZSP_CONFIG_NEIGHBOR_TABLE_SIZE
EZSP_CONFIG_TRANSPORT_PACKET_COUN T
0x03
EZSP_CONFIG_BINDING_TABLE_SIZE EZSP_CONFIG_TEMPORARY_BINDING_ENT RIES EZSP_CONFIG_TRANSPORT_CONNECTION_ COUNT EZSP_CONFIG_ROUTE_TABLE_SIZE
0x04 0x05 0x06
0x07
EZSP_CONFIG_DISCOVERY_TABLE_SIZE EZSP_CONFIG_DISCOVERY_CACHE_ENDPO INTS EZSP_CONFIG_DISCOVERY_CACHE_ENTRY _SIZE
0x08
0x09
0x0A
EZSP_CONFIG_DISCOVERY_CACHE_SIZE
0x0B
EZSP_CONFIG_STACK_PROFILE
0x0C
EZSP_CONFIG_SECURITY_LEVEL
0x0D
EZSP_CONFIG_MAX_HOPS EZSP_CONFIG_MAX_END_DEVICE_CHILDR EN
0x10 0x11
42/88
SN260 Table 25. EzspConfigId (continued)
Structure EZSP_CONFIG_INDIRECT_TRANSMISSION TIMEOUT EZSP_CONFIG_RESERVED_ROUTING_ ENTRIES EZSP_CONFIG_MOBILE_NODE_POLL_ TIMEOUT EZSP_CONFIG_RESERVED_MOBILE_CHILD ENTRIES EZSP_CONFIG_HOST_RAM EZSP_CONFIG_TX_POWER_MODE Field 0x12 0x13
EmberZNet serial protocol
Description The maximum amount of time that the MAC will hold a message for indirect transmission to a child. The number of route table entries that are reserved for temporary aggregation routes in the mesh stack. The maximum amount of time that a mobile node can wait between polls. If no poll is heard within this timeout, then the parent removes the mobile node from its tables. The number of child table entries reserved for use only by mobile nodes. The amount of RAM available for use by the Host. Enables boost power mode and/or the alternate transmitter output.
0x14
0x15 0x16 0x17
Table 26.
EzspConfigTxPowerMode
Structure Field 0x00 Description Normal power mode and bi-directional RF transmitter output. Enable boost power mode. This is a high performance radio mode which offers increased receive sensitivity and transmit power at the cost of an increase in power consumption. Enable the alternate transmitter output. This allows for simplified connection to an external power amplifier via the RF_TX_ALT_P and RF_TX_ALT_N pins. Enable both boost mode and the alternate transmitter output.
EMBER_TX_POWER_MODE_DEFAULT
EMBER_TX_POWER_MODE_BOOST
0x01
EMBER_TX_POWER_MODE_ALTERNATE EMBER_TX_POWER_MODE_BOOST_AND_ ALTERNATE
0x02
0x03
Table 27.
EzspConfigStatus
Structure Field 0x00 0x01 0x02 0x03 0x04 Description The command was successful. Insufficient memory was available. The value was out of bounds. The configuration tag was not recognized. Configuration values can no longer be modified.
EZSP_CONFIG_SUCCESS EZSP_CONFIG_OUT_OF_MEMORY EZSP_CONFIG_INVALID_VALUE EZSP_CONFIG_INVALID_TAG EZSP_CONFIG_INVALID_CALL
Table 28.
EzspPolicyId
Structure Field 0x00 0x01 0x02 Description Controls trust center behavior. Controls how external binding modification requests are handled. Controls whether the Host supplies datagram replies.
EZSP_TRUST_CENTER_POLICY EZSP_BINDING_MODIFICATION_POLICY EZSP_DATAGRAM_REPLIES_POLICY
43/88
EmberZNet serial protocol Table 28. EzspPolicyId (continued)
Structure EZSP_POLL_HANDLER_POLICY EZSP_MESSAGE_CONTENTS_IN_CALLBACK _POLICY Field 0x03 0x04 Description Controls whether pollHandler callbacks are generated.
SN260
Controls whether the message contents are included in unicastSent and messageSent callbacks.
Table 29.
EzspDecisionId
Structure Field 0x00 Description EZSP_TRUST_CENTER_POLICY default decision. Only allow nodes that are joining securely using the network key to join. EZSP_TRUST_CENTER_POLICY decision. Allow all nodes to join, sending the key to nodes that are not joining securely. EZSP_TRUST_CENTER_POLICY decision. Reject all join attempts. EZSP_TRUST_CENTER_POLICY decision. Forward the request to the trust center (this value should not be used for the trust center itself). EZSP_BINDING_MODIFICATION_POLICY default decision. Do not allow the local binding table to be changed by remote nodes. EZSP_BINDING_MODIFICATION_POLICY decision. Allow remote nodes to change the local binding table. EZSP_DATAGRAM_REPLIES_POLICY default decision. The SN260 will automatically send an empty reply (containing no payload) for every datagram received. EZSP_DATAGRAM_REPLIES_POLICY decision. The SN260 will only send a reply if it receives a sendReply command from the Host. EZSP_POLL_HANDLER_POLICY default decision. Do not inform the Host when a child polls. EZSP_POLL_HANDLER_POLICY decision. Generate a pollHandler callback when a child polls. EZSP_MESSAGE_CONTENTS_IN_CALLBACK_POLICY default decision. Include only the message tag in unicastSent and messageSent callbacks. EZSP_MESSAGE_CONTENTS_IN_CALLBACK_POLICY decision. Include both the message tag and the message contents in unicastSent and messageSent callbacks.
EZSP_ALLOW_SECURE_JOINS_ONLY
EZSP_ALLOW_ALL_JOINS
0x01
EZSP_DISALLOW_ALL_JOINS
0x02
EZSP_ASK_TRUST_CENTER
0x03
EZSP_DISALLOW_BINDING_MODIFICATIO N EZSP_ALLOW_BINDING_MODIFICATION
0x10
0x11
EZSP_HOST_WILL_NOT_SUPPLY_REPLY
0x20
EZSP_HOST_WILL_SUPPLY_REPLY
0x21
EZSP_POLL_HANDLER_IGNORE EZSP_POLL_HANDLER_CALLBACK
0x30 0x31
EZSP_MESSAGE_TAG_ONLY_IN_CALLBACK
0x40
EZSP_MESSAGE_TAG_AND_CONTENTS_IN_ CALLBACK
0x41
44/88
SN260 Table 30. EmberStatus
Structure EMBER_SUCCESS EMBER_ERR_FATAL EMBER_EEPROM_MFG_STACK_VERSION_ MISMATCH EMBER_INCOMPATIBLE_STATIC_MEMORY_ DEFINITIONS EMBER_EEPROM_MFG_VERSION_MISMATCH EMBER_EEPROM_STACK_VERSION_ MISMATCH EMBER_NO_BUFFERS EMBER_SERIAL_INVALID_BAUD_RATE EMBER_SERIAL_INVALID_PORT EMBER_SERIAL_TX_OVERFLOW EMBER_SERIAL_RX_OVERFLOW EMBER_SERIAL_RX_FRAME_ERROR EMBER_SERIAL_RX_PARITY_ERROR EMBER_SERIAL_RX_EMPTY EMBER_SERIAL_RX_OVERRUN_ERROR EMBER_MAC_TRANSMIT_QUEUE_FULL EMBER_MAC_UNKNOWN_HEADER_TYPE EMBER_MAC_SCANNING EMBER_MAC_NO_DATA EMBER_MAC_JOINED_NETWORK EMBER_MAC_BAD_SCAN_DURATION EMBER_MAC_INCORRECT_SCAN_TYPE EMBER_MAC_INVALID_CHANNEL_MASK EMBER_MAC_COMMAND_TRANSMIT_ FAILURE EMBER_MAC_NO_ACK_RECEIVED EMBER_MAC_INDIRECT_TIMEOUT Field 0x00 0x01 0x04
EmberZNet serial protocol
Description Generic 'no error' message. Generic 'fatal error' message. Manufacturing and stack token format in non-volatile memory is different than what the stack expects (returned at initialization). Static memory definitions in ember-static-memory.h are incompatible with this stack version. Manufacturing token format in non-volatile memory is different than what the stack expects (returned at initialization). Stack token format in non-volatile memory is different than what the stack expects (returned at initialization). There are no more buffers. Specified an invalid baud rate. Specified an invalid serial port. Tried to send too much data. There was not enough space to store a received character and the character was dropped. Detected a UART framing error. Detected a UART parity error. There is no received data to process. Receive interrupt was not handled in time, and a character was dropped. MAC transmit queue is full. MAC header FCR error on receive. MAC can't complete this task because it is scanning. No pending data exists for device doing a data poll. Attempt to scan when we are joined to a network. Scan duration must be 0 to 14 inclusive. Attempt was made to scan with an incorrect duration value. emberStartScan was called with an incorrect scan type. emberStartScan was called with an invalid channel mask. Failed to scan current channel because we were unable to transmit the relevant MAC command. We expected to receive an ACK following the transmission, but the MAC level ACK was never received. Indirect data message timed out before polled.
0x05
0x06
0x07 0x18 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x39 0x3A 0x3D 0x31 0x32 0x33 0x34 0x35 0x36
0x40 0x42
45/88
EmberZNet serial protocol Table 30. EmberStatus (continued)
Structure Field Description
SN260
EMBER_SIM_EEPROM_ERASE_PAGE_GREEN
0x43
Simulated EEPROM is telling the application that there is at least one flash page to be erased. GREEN status means the current page has not filled above the ERASE_CRITICAL_THRESHOLD. The application should call the function halSimEepromErasePage() when it can to erase a page. Simulated EEPROM is telling the application that there is at least one flash page to be erased. RED status means the current page has filled above the ERASE_CRITICAL_THRESHOLD. Due to the shrinking availability of write space, there is a danger of data loss. The application must call the function halSimEepromErasePage() as soon as possible to erase a page. Simulated EEPROM has run out of room to write any new data and the data trying to be set has been lost. This error code is the result of ignoring the SIM_EEPROM_ERASE_PAGE_RED error code. The application must call the function halSimEepromErasePage() to make room for any further calls to set a token. A fatal error has occurred while trying to write data to the Flash and the write verification has failed. The data in the flash cannot be trusted after this error, and it is possible this error is the result of exceeding the life cycles of the flash. Attempt 1 to initialize the simulated EEPROM has failed. This failure means the information already stored in Flash (or a lack thereof), is fatally incompatible with the token information compiled into the code image being run. Attempt 2 to initialize the simulated EEPROM has failed. This failure means Attempt 1 failed, and the token system failed to properly reload default tokens and reset the simulated EEPROM. Attempt 3 to initialize the simulated EEPROM has failed. This failure means one or both of the tokens TOKEN_MFG_NVDATA_VERSION or TOKEN_STACK_NVDATA_VERSION were incorrect and the token system failed to properly reload default tokens and reset the simulated EEPROM. An unknown flash token was specified. Could not create new flash token because it already exists. An incorrect size was specified when retrieving token data. Couldn't write token because it is marked read-only. Bootloader received an invalid message (failed attempt to go into bootloader).
EMBER_SIM_EEPROM_ERASE_PAGE_RED
0x44
EMBER_SIM_EEPROM_FULL
0x45
EMBER_SIM_EEPROM_FLASH_WRITE_ FAILED
0x46
EMBER_SIM_EEPROM_INIT_1_FAILED
0x47
EMBER_SIM_EEPROM_INIT_2_FAILED
0x48
EMBER_SIM_EEPROM_INIT_3_FAILED
0x49
EMBER_ERR_TOKEN_UNKNOWN EMBER_ERR_TOKEN_EXISTS EMBER_ERR_TOKEN_INVALID_SIZE EMBER_ERR_TOKEN_READ_ONLY EMBER_ERR_BOOTLOADER_TRAP_ TABLE_BAD
0x4B 0x4C 0x4D 0x4E 0x58
46/88
SN260 Table 30. EmberStatus (continued)
Structure EMBER_ERR_BOOTLOADER_TRAP_UNKNOWN Field 0x59
EmberZNet serial protocol
Description Bootloader received an invalid message (failed attempt to go into bootloader). Bootloader cannot complete the bootload operation because either an image was not found or the image exceeded memory bounds. EMBER_TRANSPORT_CONNECTION_COUNT limit has been reached. A connection has either been opened or is already open. A connection experienced a catastrophic error. The connection is now closed and messages may have been lost. Transport layer successfully closed a connection. Transport layer is in process of closing a connection (waiting for a response from the remote device). Transport layer attempted to send or deliver a message, but it failed. This binding index is out of range of the current binding table. Could not set or find a binding index given the specified terminal. An invalid binding table index was given to a function. Multiple binding table entries were found for the specified terminal. API call is not allowed given the current state of the stack (for example, opening a connection from a sleepy node.). Link cost to a node is not known. Maximum number of in-flight messages (such as EMBER_TRANSPORT_PACKET_COUNT) has been reached. A connection is not open yet. Message to be transmitted is too big to fit into a single over-the-air packet. Application is trying to delete or overwrite a binding that is in use. EUI64 is not available in the current packet. One or more sequenced messages failed to be received. Conversion is complete. Conversion cannot be done because a request is being processed. Conversion is deferred until the current request has been processed. No results are pending.
EMBER_ERR_BOOTLOADER_NO_IMAGE
0x5A
EMBER_TOO_MANY_CONNECTIONS EMBER_CONNECTION_OPEN EMBER_CONNECTION_FAILED EMBER_CONNECTION_CLOSED EMBER_CONNECTION_CLOSING EMBER_DELIVERY_FAILED EMBER_BINDING_INDEX_OUT_OF_RANGE EMBER_INVALID_BINDING_TERMINAL EMBER_INVALID_BINDING_INDEX EMBER_TERMINAL_HAS_MULTIPLE_ BINDINGS EMBER_INVALID_CALL EMBER_COST_NOT_KNOWN EMBER_MAX_MESSAGE_LIMIT_REACHED EMBER_CONNECTION_NOT_YET_OPEN EMBER_MESSAGE_TOO_LONG EMBER_BINDING_IS_ACTIVE EMBER_EUI64_NOT_AVAILABLE EMBER_INCOMING_SEQUENCED_MESSAGES LOST EMBER_ADC_CONVERSION_DONE EMBER_ADC_CONVERSION_BUSY EMBER_ADC_CONVERSION_DEFERRED EMBER_ADC_NO_CONVERSION_PENDING
0x60 0x61 0x63 0x64 0x65 0x66 0x69 0x6B 0x6C 0x6F 0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x80 0x81 0x82 0x84
47/88
EmberZNet serial protocol Table 30. EmberStatus (continued)
Structure EMBER_SLEEP_INTERRUPTED EMBER_PHY_TX_UNDERFLOW EMBER_PHY_TX_INCOMPLETE EMBER_PHY_INVALID_CHANNEL EMBER_PHY_INVALID_POWER EMBER_PHY_TX_BUSY Field 0x85 0x88 0x89 0x8A 0x8B 0x8C Description Sleeping (for a duration) has been abnormally interrupted and exited prematurely. Transmit hardware buffer underflowed.
SN260
Transmit hardware did not finish transmitting a packet. An unsupported channel setting was specified. An unsupported power setting was specified. Packet cannot be transmitted because the physical MAC layer is currently transmitting a packet. (This is used for the MAC backoff algorithm.) The software installed on the hardware doesn't recognize the hardware radio type. The software installed on the hardware doesn't recognize the hardware radio type. PHY did not receive the entire packet it was expecting from the radio. Stack software has completed initialization and is ready to send and receive packets over the air. Network is not operating. Network has activity pending and should not be shut down. Node has not joined a network. An attempt to join a network failed. The chosen security level (the value of EMBER_SECURITY_LEVEL) is not supported by the stack. After moving, a mobile node's attempt to re-establish contact with the network failed. A message cannot be sent because the network is currently overloaded. A datagram was sent to a node and the EUI64 address in the datagram did not match the node's EUI64 address. The NodeId was invalid. The application tried to send a message using an endpoint that it has not defined. The application tried to use a binding that has been remotely modified and the change has not yet been reported to the application. A critical and fatal error indicating that the version of the stack trying to run does not match with the chip it is running on. The software (stack) on the chip must be replaced with software that is compatible with the chip.
EMBER_PHY_UNKNOWN_RADIO_TYPE EMBER_PHY_OSCILLATOR_CHECK_FAILED EMBER_PHY_PARTIAL_PACKET EMBER_NETWORK_UP EMBER_NETWORK_DOWN EMBER_NETWORK_PENDING_ACTIVITY EMBER_NOT_JOINED EMBER_JOIN_FAILED EMBER_INVALID_SECURITY_LEVEL
0x8D 0x8E 0x8F 0x90 0x91 0x92 0x93 0x94 0x95
EMBER_MOVE_FAILED EMBER_NETWORK_BUSY
0x96 0xA1
EMBER_NODEID_INVALID
0xA2
EMBER_INVALID_ENDPOINT
0xA3
EMBER_BINDING_HAS_CHANGED
0xA4
EMBER_STACK_AND_HARDWARE_MISMATCH
0xB0
48/88
SN260 Table 31. EmberEventUnits
Structure EMBER_EVENT_INACTIVE EMBER_EVENT_MS_TIME EMBER_EVENT_QS_TIME EMBER_EVENT_MINUTE_TIME Field 0x00 0x01 0x02 0x03
EmberZNet serial protocol
Description Event is not scheduled to run. Execution time is in approximate milliseconds. Execution time is in 'binary' quarter seconds (256 approximate milliseconds each). Execution time is in 'binary' minutes (65536 approximate milliseconds each).
Table 32.
EmberNodeType
Structure Field 0x01 0x02 0x03 0x04 0x05 Description Will relay messages and can act as a parent to other nodes. Will relay messages and can act as a parent to other nodes. Communicates only with its parent and will not relay messages. An end device whose radio can be turned off to save power. The application must poll to receive messages. A sleepy end device that can move through the network.
EMBER_COORDINATOR EMBER_ROUTER EMBER_END_DEVICE EMBER_SLEEPY_END_DEVICE EMBER_MOBILE_END_DEVICE
Table 33.
EmberNetworkStatus
Structure Field 0x00 0x01 0x02 0x03 0x04 Description The node is not associated with a network in any way. The node is currently attempting to join a network. The node is joined to a network. The node is an end device joined to a network but its parent is not responding. The node is in the process of leaving its current network.
EMBER_NO_NETWORK EMBER_JOINING_NETWORK EMBER_JOINED_NETWORK EMBER_JOINED_NETWORK_NO_PARENT EMBER_LEAVING_NETWORK
Table 34.
EmberIncomingMessageType
Structure Field 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 Datagram. Datagram reply. Sequenced message. Multicast. Shared multicast. Multicast loopback. Unicast. Broadcast. Description
EMBER_INCOMING_DATAGRAM EMBER_INCOMING_DATAGRAM_REPLY EMBER_INCOMING_SEQUENCED EMBER_INCOMING_MULTICAST EMBER_INCOMING_SHARED_MULTICAST EMBER_INCOMING_MULTICAST_LOOPBACK 333EMBER_INCOMING_UNICAST EMBER_INCOMING_BROADCAST
49/88
EmberZNet serial protocol Table 35. EmberBindingType
Structure EMBER_UNUSED_BINDING EMBER_UNICAST_BINDING EMBER_AGGREGATION_BINDING Field 0x00 0x01 0x02 Description A binding that is currently not in use. A unicast binding whose 64-bit identifier is the destination EUI64. A unicast binding whose 64-bit identifier is the aggregator EUI64.
SN260
EMBER_MULTICAST_BINDING
0x03
A multicast binding whose 64-bit identifier is the group address. A multicast binding can be used to send messages to the group and to receive messages sent to the group.
Table 36.
EmberUnicastOption Structure Field 0x00 0x04 0x10 0x40 0x80 0x20 0x01 No options. Reserved. Reserved. Resend the message using the APS retry mechanism. Causes a route discovery to be initiated if no route to the destination is known. Causes a route discovery to be initiated even if one is known. Reserved. Description
EMBER_UNICAST_OPTION_NONE EMBER_UNICAST_OPTION_APS_INDIRECT EMBER_UNICAST_OPTION_HAVE_SOURCE EMBER_UNICAST_OPTION_APS_RETRY EMBER_UNICAST_OPTION_ENABLE_ROUTE DISCOVERY EMBER_UNICAST_OPTION_FORCE_ROUTE_ DISCOVERY EMBER_UNICAST_OPTION_POLL_ RESPONSE
Table 37.
EmberNetworkScanType
Structure Field 0x00 0x01 Description An energy scan scans each channel for its RSSI value. An active scan scans each channel for available networks.
EMBER_ENERGY_SCAN EMBER_ACTIVE_SCAN
Table 38.
EmberJoinDecision
Structure Field 0x00 0x01 0x02 0x03 Description Allow the node to join. The node has the key. Allow the node to join. Send the key to the node. Deny join. Ask the trust center.
EMBER_HAS_KEY EMBER_SEND_KEY EMBER_DENY_JOIN EMBER_ASK_TRUST_CENTER
50/88
SN260
EmberZNet serial protocol
7.3.4
Table 39.
Configuration frames
version
ID: 0x00
Name: version
Description: The command allows the Host to specify the desired EZSP version. This document describes version 1 of the protocol. The response provides information about the firmware running on the SN260. Command parameters: int8u desiredProtocolVersion Response parameters: int8u protocolVersion The EZSP version the SN260 is using. If the SN260 does not support the version requested by the Host, it will use the highest version it does support. The type of stack running on the SN260. The available EZSP commands and their parameters depend on the stack type. The mesh stack is type 2. The version number of the stack. The EZSP version the Host wishes to use.
int8u stackType int16u stackVersion
Table 40.
getConfigurationValue
ID: 0x52
Name: getConfigurationValue
Description: Reads a configuration value from the SN260. Command parameters: EzspConfigId configId Response parameters: EzspConfigStatus status int16u value EZSP_CONFIG_SUCCESS if the value was read successfully, EZSP_CONFIG_INVALID_ID if the SN260 does not recognize configId. The configuration value. Identifies which configuration value to read.
Table 41.
setConfigurationValue
ID: 0x53
Name: setConfigurationValue
Description: Writes a configuration value to the SN260. Configuration values can be modified by the Host after the SN260 has reset. After the stack status changes to EMBER_NETWORK_UP, configuration values can no longer be modified and this command will respond with EZSP_CONFIG_INVALID_CALL. Command parameters: EzspConfigId configId int16u value Response parameters: EZSP_CONFIG_SUCCESS if the configuration value was changed, EZSP_CONFIG_OUT_OF_MEMORY if the new value exceeded the available memory, EZSP_CONFIG_INVALID_VALUE if the new value was out of bounds, EZSP_CONFIG_INVALID_ID if the SN260 does not recognize configId, EZSP_CONFIG_INVALID_CALL if configuration values can no longer be modified. Identifies which configuration value to change. The new configuration value.
EzspConfigStatus status
51/88
EmberZNet serial protocol Table 42. addEndpoint
ID: 0x02
SN260
Name: addEndpoint
Description: Configures endpoint information on the SN260. The SN260 does not remember these settings after a reset. Endpoints can be added by the Host after the SN260 has reset. After the stack status changes to EMBER_NETWORK_UP, endpoints can no longer be added and this command will respond with EZSP_CONFIG_INVALID_CALL. Command parameters: int8u endpoint int16u profileId int16u deviceId int8u appFlags int8u inputClusterCount int8u outputClusterCount int8u[] inputClusterList int8u[] outputClusterList Response parameters: EZSP_CONFIG_SUCCESS if the endpoint was added, EZSP_CONFIG_OUT_OF_MEMORY if there is not enough memory available to add the endpoint, EZSP_CONFIG_INVALID_VALUE if the endpoint already exists, EZSP_CONFIG_INVALID_CALL if endpoints can no longer be added. The application endpoint to be added. The endpoint's application profile. The endpoint's device ID within the application profile. The device version and flags indicating description availability. The number of input clusters. The number of output clusters. Input cluster IDs the endpoint will accept. Output cluster IDs the endpoint may send.
EzspConfigStatus status
Table 43.
setPolicy
ID: 0x55
Name: setPolicy
Description: Allows the Host to change the policies used by the SN260 to make fast decisions. Command parameters: EzspPolicyId policyId EzspDecisionId decisionId Response parameters: EzspConfigStatus status EZSP_CONFIG_SUCCESS if the policy was changed, EZSP_CONFIG_INVALID_ID if the SN260 does not recognize policyId. Identifies which policy to modify. The new decision for the specified policy.
Table 44.
getPolicy
ID: 0x56
Name: getPolicy
Description: Allows the Host to read the policies used by the SN260 to make fast decisions. Command parameters: EzspPolicyId policyId Identifies which policy to read.
52/88
SN260 Table 44. getPolicy (continued)
EmberZNet serial protocol
Response parameters: EzspConfigStatus status EzspDecisionId decisionId EZSP_CONFIG_SUCCESS if the policy was read successfully, EZSP_CONFIG_INVALID_ID if the SN260 does not recognize policyId. The current decision for the specified policy.
7.3.5
Table 45.
Name: nop
Utilities frames
nop
ID: 0x05
Description: A transaction which does nothing. The Host can use this to set the sleep mode or to check the status of the SN260. Command parameters: None Response parameters: None
Table 46.
invalidCommand
ID: 0x58
Name: invalidCommand
Description: Indicates that the SN260 received a command containing an unsupported frame ID. This frame is a response to an invalid command. Response parameters: None
Table 47.
callback
ID: 0x06
Name: callback
Description: Allows the SN260 to respond with a pending callback. Command parameters: None The response to this command can be any of the callback responses.
Table 48.
noCallbacks
ID: 0x07
Name: noCallbacks
Description: Indicates that there are currently no pending callbacks. This frame is a response to the callback command. Response parameters: None
Table 49.
Name: reset
reset
ID: 0x08
Description: Allows the Host to reset the SN260. Command parameters: None Response parameters: None
53/88
EmberZNet serial protocol Table 50. setToken
ID: 0x09
SN260
Name: setToken
Description: Sets a token (8 bytes of non-volatile storage) in the simulated EEPROM of the SN260. Command parameters: int8u tokenId int8u[8] tokenData Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. Which token to set (0 to 7). The data to write to the token.
Table 51.
getToken
ID: 0x0A
Name: getToken
Description: Retrieves a token (8 bytes of non-volatile storage) from the simulated EEPROM of the SN260. Command parameters: int8u tokenId Response parameters: EmberStatus status int8u[8] tokenData An EmberStatus value indicating success or the reason for failure. The contents of the token. Which token to read (0 to 7).
Table 52.
getMfgToken
ID: 0x0B
Name: getMfgToken
Description: Retrieves a manufacturing token (8 bytes of non-volatile storage) from the Flash Information Area of the SN260. Command parameters: int8u tokenId Response parameters: EmberStatus status int8u[8] tokenData An EmberStatus value indicating success or the reason for failure. The contents of the manufacturing token. Which manufacturing token to read (0 to 7).
Table 53.
setRam
ID: 0x46
Name: setRam
Description: Writes data supplied by the Host to RAM in the SN260. The amount of RAM available for use by the Host must be set using the setConfigurationValue command. parameters int8u startIndex int8u dataLength int8u[] data Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The location to start writing the data. The length of the data parameter in bytes. The data to write to RAM.
54/88
SN260 Table 54. getRam
ID: 0x47
EmberZNet serial protocol
Name: getRam
Description: Reads data from RAM in the SN260 and returns it to the Host. Command parameters: int8u startIndex int8u length Response parameters: EmberStatus status int8u dataLength int8u[] data An EmberStatus value indicating success or the reason for failure. The length of the data parameter in bytes. The data read from RAM. The location to start reading the data. The number of bytes to read.
Table 55.
getRandomNumber
ID: 0x49
Name: getRandomNumber
Description: Returns a random number, generated using noise from the radio. Command parameters: None Response parameters: EmberStatus status int16u value An EmberStatus value indicating success or the reason for failure. If status is EMBER_SUCCESS, a random number. Otherwise, zero.
Table 56.
getMillisecondTime
ID: 0x0D
Name: getMillisecondTime
Description: Returns the current time in milliseconds according to the SN260's internal clock. Command parameters: None Response parameters: int32u time The current time in milliseconds.
Table 57.
setTimer
ID: 0x0E
Name: setTimer
Description: Sets a timer on the SN260. There are 2 independent timers available for use by the Host. A timer can be cancelled by setting time to 0 or units to EMBER_EVENT_INACTIVE. Command parameters: int8u timerId Which timer to set (0 or 1). The delay before the timerHandler callback will be generated. Note that the timer clock is free running and is not synchronized with this command. This means that the actual delay will be between time and (time - 1). The maximum delay is 32767. The units for time. If true, a timerHandler callback will be generated repeatedly. If false, only a single timerHandler callback will be generated.
int16u time
EmberEventUnits units boolean repeat
55/88
EmberZNet serial protocol Table 57. setTimer (continued)
An EmberStatus value indicating success or the reason for failure.
SN260
Response parameters EmberStatus status
Table 58.
getTimer
ID: 0x4E
Name: getTimer
Description: Gets information about a timer. The Host can use this command to find out how much longer it will be before a previously set timer will generate a callback. Command parameters: int8u timerId Response parameters: int16u time EmberEventUnits units boolean repeat The delay before the timerHandler callback will be generated. The units for time. True if a timerHandler callback will be generated repeatedly. False if only a single timerHandler callback will be generated. Which timer to get information about (0 or 1).
Table 59.
timerHandler
ID: 0x0F
Name: timerHandler Description: A callback from the timer.
This frame is a response to the callback command. Response parameters: int8u timerId Which timer generated the callback (0 or 1).
Table 60.
serialWrite
ID: 0x10
Name: serialWrite
Description: Sends a serial message from the Host to the InSight debug system via the SN260. Command parameters: int8u messageLength int8u[] messageContents Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The length of the messageContents parameter in bytes. The serial message.
56/88
SN260 Table 61. serialRead
ID: 0x11
EmberZNet serial protocol
Name: serialRead
Description: Allows the Host to read a serial message from the InSight debug system via the SN260. Command parameters: int8u length Response parameters: int8u messageLength int8u[] messageContents The length of the messageContents parameter in bytes. The serial message. The maximum number of bytes to read.
Table 62.
debugWrite
ID: 0x12
Name: debugWrite
Description: Sends a debug message from the Host to the InSight debug system via the SN260. Command parameters: boolean binaryMessage int8u messageLength int8u[] messageContents Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. TRUE if the message should be interpreted as binary data, FALSE if the message should be interpreted as ASCII text. The length of the messageContents parameter in bytes. The binary message.
Table 63.
debugHandler
ID: 0x13
Name: debugHandler
Description: Delivers a binary message from the InSight debug system to the Host via the SN260. This frame is a response to the callback command. Response parameters: int8u messageLength int8u[] messageContents The length of the messageContents parameter in bytes. The binary message.
7.3.6
Table 64.
Networking frames
setEncryptionKey
ID: 0x14
Name: setEncryptionKey
Description: Sets the encryption key used to encrypt and decrypt radio messages. This function does not work if the stack is already associated with a network. Command parameters: int8u[16] key int8u keySequenceNumber A pointer to a 16-byte encryption key. The sequence number associated with this key.
57/88
EmberZNet serial protocol Table 64. setEncryptionKey (continued)
An EmberStatus value indicating success or the reason for failure.
SN260
Response parameters: EmberStatus status
Table 65.
setManufacturerCode
ID: 0x15
Name: setManufacturerCode
Description: Sets the manufacturer code to the specified value. The manufacturer code is one of the fields of the node descriptor. Command parameters: int16u code Response parameters: None The manufacturer code for the local node.
Table 66.
setPowerDescriptor
ID: 0x16
Name: setPowerDescriptor
Description: Sets the power descriptor to the specified value. The power descriptor is a dynamic value, therefore you should call this function whenever the value changes. Command parameters: int16u descriptor Response parameters: None The new power descriptor for the local node.
Table 67.
networkInit
ID: 0x17
Name: networkInit
Description: Resume network operation after a reboot. The node retains its original type. This should be called on startup whether or not the node was previously part of a network. EMBER_NOT_JOINED is returned if the node is not part of a network. Command parameters: None Response parameters: EmberStatus status An EmberStatus value that indicates one of the following: successful initialization, EMBER_NOT_JOINED if the node is not part of a network, or the reason for failure.
Table 68.
networkState
ID: 0x18
Name: networkState
Description: Returns a value indicating whether the node is joining, joined to, or leaving a network. Command parameters: None Response parameters: EmberNetworkStatus status An EmberNetworkStatus value indicating the current join status.
58/88
SN260 Table 69. stackStatusHandler
ID: 0x19
EmberZNet serial protocol
Name: stackStatusHandler
Description: A callback invoked when the status of the stack changes. If the status parameter equals EMBER_NETWORK_UP, then the getNetworkParameters command can be called to obtain the new network parameters. If any of the parameters are being stored in nonvolatile memory by the Host, the stored values should be updated. This frame is a response to the callback command. Response parameters: EmberStatus status Stack status. One of the following: EMBER_NETWORK_UP, EMBER_NETWORK_DOWN, EMBER_JOIN_FAILED, EMBER_MOVE_FAILED
Table 70.
startScan
ID: 0x1A
Name: startScan
Description: This function will start a scan. Command parameters: EmberNetworkScanType scanType Indicates the type of scan to be performed. Possible values: EMBER_ENERGY_SCAN, EMBER_ACTIVE_SCAN. Bits set as 1 indicate that this particular channel should be scanned. Bits set to 0 indicate that this particular channel should not be scanned. For example, a channelMask value of 0x00000001 would indicate that only channel 0 should be scanned. Valid channels range from 11 to 26 inclusive. This translates to a channel mask value of 0x07FFF800. Sets the exponent of the number of scan periods, where a scan period is 960 symbols. The scan will occur for ((2^duration) + 1) scan periods.
int32u channelMask
int8u duration Response parameters:
EmberStatus status
EMBER_SUCCESS signals that the scan successfully started. Possible error responses and their meanings: EMBER_MAC_SCANNING, we are already scanning; EMBER_MAC_JOINED_NETWORK, we are currently joined to a network and can not begin a scan; EMBER_MAC_BAD_SCAN_DURATION, we have set a duration value that is not 0..14 inclusive; EMBER_MAC_INCORRECT_SCAN_TYPE, we have requested an undefined scanning type; EMBER_MAC_INVALID_CHANNEL_MASK, our channel mask did not specify any valid channels.
Table 71.
energyScanResultHandler
ID: 0x48
Name: energyScanResultHandler
Description: Reports the result of an energy scan for a single channel. The scan is not complete until the scanCompleteHandler callback is called. This frame is a response to the callback command. Response parameters: int8u channel int8u maxRssiValue The 802.15.4 channel number that was scanned. The maximum RSSI value found on the channel.
59/88
EmberZNet serial protocol Table 72. networkFoundHandler
ID: 0x1B
SN260
Name: networkFoundHandler
Description: Reports that a network was found, and gives the network parameters useful for deciding which network to join. This frame is a response to the callback command. Response parameters: int8u channel int16u panId boolean expectingJoin int8u stackProfile The 802.15.4 channel number on which the current network was found. The PAN ID of the current network. Whether the node that generated this beacon is allowing additional children to join to its network. The ZigBee profile number of the current network.
Table 73.
scanCompleteHandler
ID: 0x1C
Name: scanCompleteHandler
Description: Returns the status of the current scan. EMBER_SUCCESS signals that the scan has completed. Other error conditions signify a failure to scan on the channel specified. This frame is a response to the callback command. Response parameters: int8u channel EmberStatus status The channel on which the current error occurred. Undefined for the case of EMBER_SUCCESS. The error condition that occurred on the current channel. Value will be EMBER_SUCCESS when the scan has completed.
Table 74.
stopScan
ID: 0x1D
Name: stopScan
Description: Terminates a scan in progress. Command parameters: None Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure.
Table 75.
formNetwork
ID: 0x1E
Name: formNetwork
Description: Forms a new network by becoming the coordinator. Command parameters: EmberNetworkParameters Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. Specification of the new network.
60/88
SN260 Table 76. joinNetwork
ID: 0x1F
EmberZNet serial protocol
Name: joinNetwork
Description: Causes the stack to associate with the network using the specified network parameters. It can take several seconds for the stack to associate with the local network. Do not send messages until the stackStatusHandler callback informs you that the stack is up. Command parameters: EmberNodeType nodeType EmberNetworkParameters Specification of the role that this node will have in the network. This role must not be EMBER_COORDINATOR. To be a coordinator, use the formNetwork command. Specification of the network with which the node should associate. If true, the node uses the current key to secure messages during the joining process. The proper value for secured networks depends upon their configuration. Some networks use unsecured joining and distribute the key from the coordinator. Other networks require secure joining and accept only nodes that know the correct key. This value has no effect if the security level is 0.
boolean joinSecurely
Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure.
Table 77.
scanAndFormNetwork
ID: 0x4F
Name: scanAndFormNetwork
Description: Scan for an available channel and PAN ID then form a network. This performs the following actions: 1. Performs an energy scan on the indicated channels and randomly chooses one from amongst those with the least average energy. 2. Randomly picks a PAN ID that does not appear during an active scan on the chosen channel. 3. Forms a network using the chosen channel and PAN ID. If any errors occur the status code is passed to the scanErrorHandler callback and no network is formed. Success is indicated when the stackStatusHandler callback is invoked with the EMBER_NETWORK_UP status value. Command parameters: Bits set as 1 indicate that this particular channel should be scanned. Bits set to 0 indicate that this particular channel should not be scanned. For example, a channelMask value of 0x00000001 would indicate that only channel 0 should be scanned. Valid channels range from 11 to 26 inclusive. This translates to a channel mask value of 0x07FFF800. A power setting, in dBm.
int32u channelMask
int8s radioTxPower Response parameters: None
Table 78.
scanAndJoinNetwork
ID: 0x50
Name: scanAndJoinNetwork
Description: Scan and join a network. This performs the following actions: 1. Does an active scan to find a network that uses our stack profile and currently allows new nodes to join. 2. Joins the chosen network. If any errors occur the status code is passed to the scanErrorHandler callback and no network is joined. Success is indicated when the stackStatusHandler callback is invoked with the EMBER_NETWORK_UP status value.
61/88
EmberZNet serial protocol Table 78. scanAndJoinNetwork (continued)
SN260
Command parameters: EmberNodeType nodeType Specification of the role that this node will have in the network. This role must not be EMBER_COORDINATOR. To be a coordinator, use the scanAndformNetwork command. Bits set as 1 indicate that this particular channel should be scanned. Bits set to 0 indicate that this particular channel should not be scanned. For example, a channelMask value of 0x00000001 would indicate that only channel 0 should be scanned. Valid channels range from 11 to 26 inclusive. This translates to a channel mask value of 0x07FFF800. A power setting, in dBm. If true, the node uses the current key to secure messages during the joining process. The proper value for secured networks depends upon their configuration. Some networks use unsecured joining and distribute the key from the coordinator. Other networks require secure joining and accept only nodes that know the correct key. This value has no effect if the security level is 0.
int32u channelMask
int8s radioTxPower
boolean joinSecurely
Response parameters: None
Table 79.
scanErrorHandler
ID: 0x51
Name: scanErrorHandler
Description: This callback is invoked if an error occurs while attempting to scanAndFormNetwork or scanAndJoinNetwork. This frame is a response to the callback command. Response parameters: EmberStatus status An EmberStatus value indicating the reason for the scanAndFormNetwork or scanAndJoinNetwork failure.
Table 80.
leaveNetwork
ID: 0x20
Name: leaveNetwork
Description: Causes the stack to leave the current network. This generates a stackStatusHandler callback to indicate that the network is down. The radio will not be used until after sending a formNetwork or joinNetwork command. Command parameters: None Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure.
Table 81.
mobileNodeHasMoved
ID: 0x21
Name: mobileNodeHasMoved
Description: Informs the stack that contact with the network has been lost. Only devices that are joined to a network with a node type of EMBER_MOBILE_END_DEVICE may call this function. This generates a stackStatusHandler callback to indicate that the network is down. The stack will try to re-establish contact with the network. A second stackStatusHandler callback indicates either the success or the failure of the attempt. Command parameters: None
62/88
SN260 Table 81. mobileNodeHasMoved (continued)
EmberZNet serial protocol
Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure.
Table 82.
permitJoining
ID: 0x22
Name: permitJoining
Description: Tells the stack to allow other nodes to join the network with this node as their parent. Joining is initially disabled by default. Command parameters: int8u duration Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. A value of 0x00 disables joining. A value of 0xFF enables joining. Any other value enables joining for that number of seconds.
Table 83.
childJoinHandler
ID: 0x23
Name: childJoinHandler
Description: Indicates that a child has joined or left. This frame is a response to the callback command. Response parameters: int8u index boolean joining EmberNodeId childId EmberEUI64 childEui64 EmberNodeType childType The index of the child of interest. True if the child is joining. False the child is leaving. The node ID of the child. The EUI64 of the child. The node type of the child.
Table 84.
trustCenterJoinHandler
ID: 0x24
Name: trustCenterJoinHandler
Description: The SN260 used the trust center behavior policy to decide whether to allow a new node to join the network. The Host cannot change the current decision, but it can change the policy for future decisions using the setPolicy command. This frame is a response to the callback command. Response parameters: EmberEUI64 newNode boolean securedJoin EmberJoinDecision policyDecision The EUI64 of the node that wished to join. True if the node was joining securely using the network security key. An EmberJoinDecision reflecting the decision made.
63/88
EmberZNet serial protocol Table 85. sendDiscoveryInformationToParent
SN260
Name: ID: 0x25 sendDiscoveryInformationToParent Description: Initiates the upload of discovery information to the parent of this node. Only devices that are joined to a network with a node type of EMBER_SLEEPY_END_DEVICE may call this function. The parent stores the information in its discovery cache. The information is sent using ZDO messages with cluster IDs NODE_DESCRIPTOR_RESPONSE, POWER_DESCRIPTOR_RESPONSE and SIMPLE_DESCRIPTOR_RESPONSE. Command parameters: None Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure.
Table 86.
getEui64
ID: 0x26
Name: getEui64
Description: Returns the EUI64 ID of the local node. Command parameters: None Response parameters: EmberEUI64 eui64 The 64-bit ID.
Table 87.
getNodeId
ID: 0x27
Name: getNodeId
Description: Returns the 16-bit node ID of the local node. Command parameters: None Response parameters: EmberNodeId nodeId The 16-bit ID.
Table 88.
getNetworkParameters
ID: 0x28
Name: getNetworkParameters
Description: Returns the current network parameters. Command parameters: None Response parameters: EmberStatus status EmberNodeType nodeType EmberNetworkParameters An EmberStatus value indicating success or the reason for failure. An EmberNodeType value indicating the current node type. The current network parameters.
Table 89.
getParentChildParameters
ID: 0x29
Name: getParentChildParameters
Description: Returns information about the children of the local node and the parent of the local node. Command parameters: None
64/88
SN260 Table 89. getParentChildParameters (continued)
EmberZNet serial protocol
Response parameters: int8u childCount EmberEUI64 parentEui64 EmberNodeId parentNodeId The number of children the node currently has. The parent's EUI64. The value is undefined for nodes without parents (coordinators and nodes that are not joined to a network). The parent's node ID. The value is undefined for nodes without parents (coordinators and nodes that are not joined to a network).
Table 90.
getChildData
ID: 0x4A
Name: getChildData
Description: Returns information about a child of the local node. Command parameters: int8u index Response parameters: EmberStatus status EmberNodeId childId EmberEUI64 childEui64 EmberNodeType childType EMBER_SUCCESS if there is a child at index. EMBER_NOT_JOINED if there is no child at index. The node ID of the child. The EUI64 of the child. The EmberNodeType value for the child. The index of the child of interest in the child table. Possible indexes range from zero to EMBER_CHILD_TABLE_SIZE.
7.3.7
Table 91.
Binding frames
clearBindingTable
ID: 0x2A
Name: clearBindingTable
Description: Deletes all binding table entries. Command parameters: None Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure.
Table 92.
setBinding
ID: 0x2B
Name: setBinding
Description: Sets an entry in the binding table. Command parameters: int8u index EmberBindingTableEntry value Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The index of a binding table entry. The contents of the binding entry.
65/88
EmberZNet serial protocol Table 93. getBinding
ID: 0x2C
getBinding
SN260
Name: getBinding
Description: Gets an entry from the binding table. Command parameters: int8u index Response parameters: EmberStatus status EmberBindingTableEntry value An EmberStatus value indicating success or the reason for failure. The contents of the binding entry. The index of a binding table entry.
Table 94.
deleteBinding
ID: 0x2D
Name: deleteBinding
Description: Deletes a binding table entry. Command parameters: int8u index Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The index of a binding table entry.
Table 95.
bindingIsActive
ID: 0x2E
Name: bindingIsActive
Description: Indicates whether a binding table entry is active--that is, whether a connection to it is open or any messages are en route from it. Note that this command does not indicate whether a binding is clear. To determine whether a binding is clear, check whether the type field of the EmberBindingTableEntry has the value EMBER_UNUSED_BINDING. Command parameters: int8u index Response parameters: boolean active True if the binding table entry is active. False if the binding table entry is not active. The index of a binding table entry.
Table 96.
getBindingDestinationNodeId
ID: 0x2F
Name: getBindingDestinationNodeId
Description: Returns the node ID for the binding's destination, if the ID is known. If a message is sent using the binding and the destination's ID is not known, the stack will discover the ID by broadcasting a ZDO address request. The application can avoid the need for this discovery by using setBindingDestinationNodeId when it knows the correct ID via some other means. The destination's node ID is forgotten when the binding is changed, when the local node reboots or, much more rarely, when the destination node changes its ID in response to an ID conflict. Command parameters: int8u index The index of a binding table entry.
66/88
SN260 Table 96. getBindingDestinationNodeId (continued)
EmberZNet serial protocol
Response parameters: EmberNodeId nodeId The short ID of the destination node or EMBER_NULL_NODE_ID if no destination is known.
Table 97.
setBindingDestinationNodeId
ID: 0x30
Name: setBindingDestinationNodeId
Description: Set the node ID for the binding's destination. See getBindingDestinationNodeId for a description. Command parameters: int8u index EmberNodeId nodeId Response parameters: None The index of a binding table entry. The short ID of the destination node.
Table 98.
remoteSetBindingHandler
ID: 0x31
Name: remoteSetBindingHandler
Description: The SN260 used the external binding modification policy to decide how to handle a remote set binding request. The Host cannot change the current decision, but it can change the policy for future decisions using the setPolicy command. This frame is a response to the callback command. Response parameters: EmberBindingTableEntry entry int8u index EmberStatus policyDecision The requested binding. The index at which the binding was added. EMBER_SUCCESS if the binding was added to the table and any other status if not.
Table 99.
remoteDeleteBindingHandler
ID: 0x32
Name: remoteDeleteBindingHandler
Description: The SN260 used the external binding modification policy to decide how to handle a remote delete binding request. The Host cannot change the current decision, but it can change the policy for future decisions using the setPolicy command. This frame is a response to the callback command. Response parameters: int8u index EmberStatus policyDecision The index of the binding whose deletion was requested. EMBER_SUCCESS if the binding was removed from the table and any other status if not.
67/88
EmberZNet serial protocol
SN260
7.3.8
Messaging frames
Table 100. maximumPayloadLength
Name: maximumPayloadLength Command parameters: None Response parameters: int8u apsLength int8u transportLength The maximum APS payload length. The maximum transport payload length. ID: 0x33
Table 101. sendUnicast
Name: sendUnicast ID: 0x34
Description: Sends a unicast message as per the ZigBee specification. The message will arrive at its destination only if there is a known route to the destination node. Setting the ENABLE_ROUTE_DISCOVERY option will cause a route to be discovered if none is known. Setting the FORCE_ROUTE_DISCOVERY option will force route discovery. Routes to end-device children of the local node are always known. Setting the APS_RETRY option will cause the message to be retransmitted until either a matching acknowledgement is received or three transmissions have been made. The ZigBee APS retry mechanism does not use sequence numbers. If multiple messages are sent to the same destination at the same time any acknowledgement from that node will stop transmission of all outstanding messages. Note: Using the FORCE_ROUTE_DISCOVERY option will cause the first transmission to be consumed by a route request as part of discovery, so the application payload of this packet will not reach its destination on the first attempt. If you want the packet to reach its destination, the APS_RETRY option must be set so that another attempt is made to transmit the message with its application payload after the route has been constructed. Command parameters: EmberNodeId destination EmberApsFrame apsFrame int8u messageTag int8u messageLength int8u[] messageContents Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The node ID to which the message will be sent. The APS frame for the message. A value chosen by the Host. This value is used in the emberUnicastSent response to refer to this message. The length of the messageContents parameter in bytes. The unicast message.
Table 102. unicastSent
Name: unicastSent ID: 0x35
Description: A callback indicating the stack has completed sending a non-transport unicast message. Except for the status value, the parameters are identical to those of the sendUnicast command used to send the message. This frame is a response to the callback command. Response parameters: EmberNodeId destination EmberApsFrame apsFrame The node ID to which the message was be sent. The APS frame for the message.
68/88
SN260 Table 102. unicastSent (continued)
int8u messageTag EmberStatus status int8u messageLength int8u[] messageContents
EmberZNet serial protocol
The value supplied by the Host in the emberSendUnicast command. An EmberStatus value indicating success or the reason for failure. The length of the messageContents parameter in bytes. The unicast message supplied by the Host. The message contents are only included here if the decision for the messageContentsInCallback policy is messageTagAndContentsInCallback.
Table 103. sendBroadcast
Name: sendBroadcast ID: 0x36
Description: Sends a broadcast message as per the ZigBee specification. Command parameters: EmberApsFrame apsFrame int8u radius int8u messageTag int8u messageLength int8u[] messageContents Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The APS frame for the message. The message will be delivered to all nodes within radius hops of the sender. A radius of zero is converted to EMBER_MAX_HOPS. Reserved for future use. This value is ignored by the SN260. The length of the messageContents parameter in bytes. The broadcast message.
Table 104. sendDatagram
Name: sendDatagram ID: 0x37
Description: Sends a datagram to the node and endpoint specified in a binding table entry. The status of the delivery will be reported by a messageSent callback. Command parameters: int8u bindingTableIndex int8u clusterId int8u messageTag int8u messageLength int8u[] messageContents The index of the binding table entry. The cluster ID to use. A value chosen by the Host. This value is used in the emberCancelMessage command and the emberMessageSent response to refer to this message. The length of the messageContents parameter in bytes. The datagram message.
69/88
EmberZNet serial protocol Table 104. sendDatagram (continued)
Response parameters:
SN260
EmberStatus status
An EmberStatus value. For any result other than EMBER_SUCCESS, the message will not be sent. EMBER_SUCCESS: The message has been submitted for transmission. EMBER_INVALID_BINDING_INDEX: The bindingTableIndex refers to a non-unicast binding. EMBER_NETWORK_DOWN: The node is not part of a network. EMBER_MESSAGE_TOO_LONG: The message is too large to fit in a MAC layer frame. EMBER_MAX_MESSAGE_LIMIT_REACHED: The EMBER_TRANSPORT_PACKET_COUNT limit has been reached.
Table 105. sendMulticast
Name: sendMulticast ID: 0x38
Description: Sends a multicast message to all endpoints that share a specific multicast ID and are within a specified number of hops of the sender. Command parameters: int8u bindingTableIndex int8u clusterId int8u messageTag int8u hops int8u messageLength int8u[] messageContents Response parameters: An EmberStatus value. For any result other than EMBER_SUCCESS, the message will not be sent. EMBER_SUCCESS: The message has been submitted for transmission. EMBER_INVALID_BINDING_INDEX: The bindingTableIndex refers to a non-multicast binding. EMBER_NETWORK_DOWN: The node is not part of a network. EMBER_MESSAGE_TOO_LONG: The message is too large to fit in a MAC layer frame. EMBER_NO_BUFFERS: The free packet buffer pool is empty. EMBER_NETWORK_BUSY: Insufficient resources available in Network or MAC layers to send message. The index of the binding table entry specifying the multicast group. The cluster ID to use. Reserved for future use. This value is ignored by the SN260. The message will be delivered to all nodes within this number of hops of the sender. A value of zero is converted to EMBER_MAX_HOPS. The length of the messageContents parameter in bytes. The multicast message.
EmberStatus status
Table 106. sendReply
Name: sendReply ID: 0x39
Description: Sends a reply to a received datagram message. The incomingMessageHandler callback for the datagram being replied to supplies the values for all the parameters except the reply itself. Command parameters: EmberNodeId sender Value supplied by incoming datagram.
70/88
SN260 Table 106. sendReply (continued)
EmberApsFrame apsFrame int8u datagramReplyTag int8u messageLength int8u[] messageContents Response parameters: EmberStatus status Value supplied by incoming datagram. Value supplied by incoming datagram.
EmberZNet serial protocol
The length of the messageContents parameter in bytes. The reply message.
An EmberStatus value indicating success or the reason for failure.
Table 107. openConnection
Name: openConnection ID: 0x3A
Description: Opens a sequenced connection to a node. Command parameters: int8u bindingTableIndex Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The index of the binding table entry to which a connection will be opened.
Table 108. connectionStatus
Name: connectionStatus ID: 0x3B
Description: Returns the connection status of a binding table entry. Command parameters: int8u bindingTableIndex Response parameters: An EmberStatus value: EMBER_CONNECTION_CLOSED: The connection is closed. EMBER_CONNECTION_NOT_YET_OPEN: The connection is in the process of being established. EMBER_CONNECTION_OPEN: The connection is currently established. EMBER_CONNECTION_CLOSING: The connection is in the process of being closed. The index of the binding table entry whose status is being queried.
EmberStatus status
Table 109. connectionStatusHandler
Name: connectionStatusHandler ID: 0x3C
Description: A callback indicating the status of a connection has changed. This frame is a response to the callback command.
71/88
EmberZNet serial protocol Table 109. connectionStatusHandler (continued)
Response parameters: int8u bindingTableIndex
SN260
The index of the binding table entry whose connection status has changed. An EmberStatus value: EMBER_CONNECTION_OPEN: A sequenced connection has successfully been established for the binding. It may have been initiated locally or remotely. EMBER_CONNECTION_CLOSING: The sequenced connection for the binding is being closed gracefully. The close may have been initiated locally or remotely. As soon as the disposition of all in-flight messages has been resolved the connection will be completely closed (and the EMBER_CONNECTION_CLOSED status will be reported). EMBER_CONNECTION_CLOSED: The sequenced connection has been successfully closed. The disposition of every message sent over the connection has already been reported (via the various callbacks). There will be no further message related callbacks. EMBER_CONNECTION_FAILED: The sequenced connection has been closed unexpectedly. If there were messages in-flight their disposition will never be known or reported via callbacks. This error may be reported during the opening of a connection, while a connection is established or during the closing of a connection. EMBER_INCOMING_SEQUENCED_MESSAGES_LOST: One or more sequenced messages have not been received on the connection and it has been determined they will never be received.
EmberStatus status
Table 110. sendSequenced
Name: sendSequenced ID: 0x3D
Description: Sends a sequenced message over the connection associated with a specified binding table entry. command parameters: int8u bindingTableIndex int8u clusterId int8u messageTag int8u messageLength int8u[] messageContents The index of the binding table entry specifying the message destination. The cluster ID to use. A value chosen by the Host. This value is used in the emberCancelMessage command and the emberMessageSent response to refer to this message. The length of the messageContents parameter in bytes. The sequenced message.
72/88
SN260 Table 110. sendSequenced (continued)
Response parameters:
EmberZNet serial protocol
EmberStatus status
An EmberStatus value. For any result other than EMBER_SUCCESS, the message will not be sent. EMBER_SUCCESS: The message has been submitted for transmission. EMBER_CONNECTION_CLOSED: The connection associated with bindingTableIndex is either closed or in the process of closing. EMBER_INVALID_BINDING_INDEX: The bindingTableIndex refers to a non-unicast binding. EMBER_NETWORK_DOWN: The node is not part of a network. EMBER_MESSAGE_TOO_LONG: The message is too large to fit in a MAC layer frame. EMBER_MAX_MESSAGE_LIMIT_REACHED: Either the EMBER_TRANSPORT_PACKET_COUNT limit has been reached or the transmit window is full (i.e. there are already 8 sequenced messages in flight on the connection).
Table 111. closeConnection
Name: closeConnection ID: 0x3E
Description: Closes a connection. Any sequenced messages previously sent on the connection will be delivered before the connection is closed. Similarly, all messages sent by the remote node before the connection close is initiated will be received before the connection closes locally. Command parameters: int8u bindingTableIndex Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The index of the binding table entry whose connection is to be closed.
Table 112. messageSent
Name: messageSent ID: 0x3F
Description: A callback indicating the stack has completed sending a datagram or sequenced message. This frame is a response to the callback command. Response parameters: int8u bindingTableIndex int8u clusterId int8u messageTag The index of the binding table entry to which the message was sent. The cluster ID that was used. The value supplied by the Host in the emberSendDatagram or emberSendSequenced command. An EmberStatus value of EMBER_SUCCESS if an ACK was received from the destination or EMBER_DELIVERY_FAILED if no ACK was received. The length of the messageContents parameter in bytes. The unicast message supplied by the Host. The message contents are only included here if the decision for the messageContentsInCallback policy is messageTagAndContentsInCallback.
EmberStatus status int8u messageLength int8u[] messageContents
73/88
EmberZNet serial protocol Table 113. cancelMessage
Name: cancelMessage ID: 0x40
SN260
Description: Cancels an outgoing message. Command parameters: int8u messageTag Response parameters: EmberStatus status Always returns EMBER_SUCCESS. The value supplied by the Host in the emberSendDatagram or emberSendSequenced command.
Table 114. createAggregationRoutes
Name: createAggregationRoutes ID: 0x41
Description: Sends a route request that creates routes from every node in the network back to this node. This function should be called by the application if it wishes to aggregate data from many nodes. The data sources will not have to discover routes individually. Additionally, incoming data will set up temporary reverse routes that allow acknowledgement messages to return without a route discovery. The temporary routes expire and become reusable after a single use, or 10-20 seconds. Command parameters: None Response parameters: EmberStatus status EMBER_SUCCESS if the route request was successfully submitted to the transmit queue, and EMBER_ERR_FATAL otherwise.
Table 115. pollForData
Name: pollForData ID: 0x42
Description: Periodically request any pending data from our parent. Setting interval to 0 or units to EMBER_EVENT_INACTIVE will generate a single poll. Command parameters: int16u interval EmberEventUnits units The time between polls. Note that the timer clock is free running and is not synchronized with this command. This means that the time will be between interval and (interval - 1). The maximum interval is 32767. The units for interval. The number of poll failures that will be tolerated before a pollCompleteHandler callback is generated. A value of zero will result in a callback for every poll. Any status value apart from EMBER_SUCCESS and EMBER_MAC_NO_DATA is counted as a failure.
int8u failureLimit
Response parameters: EmberStatus status The result of sending the first poll.
Table 116. pollCompleteHandler
Name: pollCompleteHandler ID: 0x43
Description: Indicates the result of a data poll to the parent of the local node. This frame is a response to the callback command.
74/88
SN260 Table 116. pollCompleteHandler (continued)
Response parameters:
EmberZNet serial protocol
EmberStatus status
An EmberStatus value: EMBER_SUCCESS: Data was received in response to the poll. EMBER_MAC_NO_DATA: No data was pending. EMBER_DELIVERY_FAILED: The poll message could not be sent. EMBER_MAC_NO_ACK_RECEIVED: The poll message was sent but not acknowledged by the parent.
Table 117. pollHandler
Name: pollHandler ID: 0x44
Description: Indicates that the local node received a data poll from a child. This frame is a response to the callback command. Response parameters: EmberNodeId childId The node ID of the child that is requesting data.
Table 118. incomingMessageHandler
Name: incomingMessageHandler ID: 0x45
Description: A callback indicating a message has been received. This frame is a response to the callback command. Response parameters: The type of the incoming message. One of the following: EMBER_INCOMING_DATAGRAM, EMBER_INCOMING_DATAGRAM_REPLY, EMBER_INCOMING_SEQUENCED, EMBER_INCOMING_MULTICAST, EMBER_INCOMING_SHARED_MULTICAST, EMBER_INCOMING_MULTICAST_LOOPBACK, EMBER_INCOMING_UNICAST, EMBER_INCOMING_BROADCAST The APS frame from the incoming message. The link quality from the node that last relayed the message. The energy level (in units of dBm) observed during the reception. The sender of the message. The index of a binding that matches the message or 0xFF if there is no matching binding. If the incoming message is a datagram and the Host wishes to send a reply, this value must be supplied to the emberSendReply command. The length of the messageContents parameter in bytes. The incoming message.
EmberIncomingMessageType type
EmberApsFrame apsFrame int8u lastHopLqi int8s lastHopRssi EmberNodeId sender int8u bindingIndex int8u datagramReplyTag int8u messageLength int8u[] messageContents
75/88
EmberZNet serial protocol
SN260
7.3.9
Alphabetical list of frames
Table 119. Alphabetical list of frames
Frame Name addEndpoint bindingIsActive callback cancelMessage childJoinHandler clearBindingTable closeConnection connectionStatus connectionStatusHandler createAggregationRoutes debugHandler debugWrite deleteBinding energyScanResultHandler formNetwork getBinding getBindingDestinationNodeId getChildData getConfigurationValue getEui64 getMfgToken getMillisecondTime getNetworkParameters getNodeId getParentChildParameters getPolicy getRam getRandomNumber getTimer getToken incomingMessageHandler invalidCommand joinNetwork ID 0x02 0x2E 0x06 0x40 0x23 0x2A 0x3E 0x3B 0x3C 0x41 0x13 0x12 0x2D 0x48 0x1E 0x2C 0x2F 0x4A 0x52 0x26 0x0B 0x0D 0x28 0x27 0x29 0x56 0x47 0x49 0x4E 0x0A 0x45 0x58 0x1F
76/88
SN260 Table 119. Alphabetical list of frames (continued)
Frame Name leaveNetwork maximumPayloadLength messageSent mobileNodeHasMoved networkFoundHandler networkInit networkState noCallbacks nop openConnection permitJoining pollCompleteHandler pollForData pollHandler remoteDeleteBindingHandler remoteSetBindingHandler reset scanAndFormNetwork scanAndJoinNetwork scanCompleteHandler scanErrorHandler sendBroadcast sendDatagram sendDiscoveryInformationToParent sendMulticast sendReply sendSequenced sendUnicast serialRead serialWrite setBinding setBindingDestinationNodeId setConfigurationValue setEncryptionKey setManufacturerCode
EmberZNet serial protocol
ID 0x20 0x33 0x3F 0x21 0x1B 0x17 0x18 0x07 0x05 0x3A 0x22 0x43 0x42 0x44 0x32 0x31 0x08 0x4F 0x50 0x1C 0x51 0x36 0x37 0x25 0x38 0x39 0x3D 0x34 0x11 0x10 0x2B 0x30 0x53 0x14 0x15
77/88
EmberZNet serial protocol Table 119. Alphabetical list of frames (continued)
Frame Name setPolicy setPowerDescriptor setRam setTimer setToken stackStatusHandler startScan stopScan timerHandler trustCenterJoinHandler unicastSent version ID 0x55 0x16 0x46 0x0E 0x09 0x19 0x1A 0x1D 0x0F 0x24 0x35 0x00
SN260
7.4
Sample transactions
This section provides illustrations of the following sample transactions:

Joining Binding Sending Receiving
7.4.1
Joining
1) frame control joinNetwork command nodeType panId radioTxPower radioChannel useKey = = = = = = = 0x00 (command frame, don't sleep) 0x1F 0x02 (EMBER_ROUTER) 0x1234 0xFF (-1) 0x0B (11) 0x00 (FALSE)
HOST -> SN260: | 00 | 1F | 02 | 34 | 12 | FF | 0B | 00 | = 0x80 (response frame, no overflow, not truncated) joinNetwork response = 0x1F status = 0x00 (EMBER_SUCCESS) SN260 -> HOST: | 80 | 1F | 00 | 2) Host waits for callback signal while SN260 tries to join the network. frame control
78/88
SN260 3)
EmberZNet serial protocol frame control = 0x00 (command frame, don't sleep) callback command = 0x06 HOST -> SN260: | 00 | 06 | frame control = 0x80 (response frame, no overflow, not truncated) stackStatusHandler response = 0x19 status = 0x90 (EMBER_NETWORK_UP) SN260 -> HOST: | 80 | 19 | 90 |
7.4.2
Binding
1) frame control setBinding command index type local remote clusterId identifier = = = = = = = = 0x00 (command frame, don't sleep) 0x2B 0x00 0x01 (EMBER_UNICAST_BINDING) 0x11 0x12 0x55 0x1122334455667788
HOST -> SN260: | 00 | 2B | 00 | 01 | 11 | 12 | 55 | 88 | 77 | 66 | 55 | 44 | 33 | 22 | 11 | = 0x80 (response frame, no overflow, not truncated) setBinding response = 0x2B status = 0x00 (EMBER_SUCCESS) SN260 -> HOST: | 80 | 2B | 00 | frame control
7.4.3
Sending
1) frame control sendDatagram command bindingTableIndex clusterId messageTag messageLength messageContents = = = = = = = 0x00 (command frame, don't sleep) 0x37 0x00 0x55 0x01 0x03 0xE1, 0xE2, 0xE3
HOST -> SN260: | 00 | 37 | 00 | 55 | 01 | 03 | E1 | E2 | E3 | = 0x80 (response frame, no overflow, not truncated) sendDatagram response = 0x37 status = 0x00 (EMBER_SUCCESS) SN260 -> HOST: | 80 | 37 | 00 | frame control
79/88
EmberZNet serial protocol
SN260
2) Host waits for callback signal while SN260 tries to send the message. 3) frame control = 0x00 (command frame, don't sleep) callback command = 0x06 HOST -> SN260: | 00 | 06 | frame control truncated) messageSent response bindingTableIndex clusterId messageTag status = 0x80 (response frame, no overflow, not = = = = = 0x3F 0x00 0x55 0x01 0x00 (EMBER_SUCCESS)
SN260 -> HOST: | 80 | 3F | 00 | 55 | 01 | 00 |
7.4.4
Receiving
1) Host waits for callback signal after a message is received by the SN260. 2) frame control = 0x00 (command frame, don't sleep) callback command = 0x06 HOST -> SN260: | 00 | 06 | = 0x80 (response frame, no overflow, not truncated) incomingMessageHandler response = 0x45 type = 0x00 (EMBER_INCOMING_DATAGRAM) profileId = 0xABCD clusterId = 0x55 sourceEndpoint = 0x11 destinationEndpoint = 0x12 options = 0x00 lastHopLqi = 0xF0 lastHopRssi = 0xC4 (-60) sender = 0x0001 bindingIndex = 0xFF datagramReplyTag = 0x01 messageLength = 0x03 messageContents = 0xE1, 0xE2, 0xE3
SN260 -> HOST: | 80 | 45 | 00 | CD | AB | 55 | 11 | 12 | 00 | F0 | C4 | 01 | 00 | FF | 01 | 03 | E1 | E2 | E3 |
frame control
80/88
SN260
SIF module programming and debug interface
8
SIF module programming and debug interface
SIF is a synchronous serial interface developed by Cambridge Consultants Ltd. It is the primary programming and debug interface of the SN260. Therefore, any design implementing the SN260 should make the SIF signals readily available. The SIF module allows external devices to read and write memory-mapped registers in real-time without changing the functionality or timing of the XAP2b core. See the SN260 reference design for details regarding the implementation of the SIF interface.Go to www.stmcu.com for details. The SIF interface provides the following:

IC production test (especially analog) PCB production test Firmware download Product control and characterization nSIF_LOAD SIF_CLK SIF_MOSI SIF_MISO
The pins are:

The maximum serial shift speed for the SIF interface is 48MHz. SIF interface accesses can be initiated even when the chip is in idle, deep sleep, or power down modes. An edge on nSIF_LOAD wakes the chip to allow SIF cycles.
81/88
Typical application
SN260
9
Typical application
Figure 12 illustrates the typical application circuit for the SN260. This figure does not contain all decoupling capacitance required by the SN260. The Balun provides the impedance transformation from the antenna to the SN260 for both TX and RX modes. The harmonic filter provides additional suppression of the second harmonic, which increases the margin over the FCC limit. The 24MHz crystal with loading capacitors is required and provides the high frequency source for the SN260. The RC debounce filter (R4 and C7) is suggested to improve the noise immunity of the nRESET logic (Pin 11). The SIF (nSIF_LOAD, SIF_MOSI, SIF_MISO, and SIF_CLK) and packet trace signals (PTI_EN and PTI_TXD) should be brought out test points or, if space permits to a 10-pin, dual row, 0.05-inch pitch header footprint. With a header populated, a direct connection to the InSight Adapter is possible which enhances the debug capability of the SN260. For more information, refer to www.stmcu.com.
Figure 12. Typical application circuit
C4 1.8V
LINK_ACTIVITY
X1
C5
VDD_SYNTH_PRE
Route to LED or leave unconnected Programming and Debug Interface (these pins should be routed to test points)
GND
R3
VDD_24MHZ
1.8V
40 39 38 37 36 35 34 33 32 31 VDD_VCO
VDD_FLASH
VDD_CORE
nWAKE
SDBG
OSCA
OSCB
L2
C1 Ceram ic Balun (BLN1) C2 L1
1 2 3 4 5 6 7 8 9 10
RF_P RF_N VDD_RF RF_TX_ALT_P RF_TX_ALT_N VDD_IF BIAS_R VDD_PADSA TX_ACTIVE
41 GND
30 29 28
nSIF_LOAD SIF_MOSI SIF_MISO SIF_CLK nHOST_INT RES VDD_PADS PTI_DATA PTI_EN nSSEL
C3
Harmonic Filter
U1
27 26 25 24 23 22 21
SN260 EM260
R1 R2
11 12 13 14 15 16 17 18 19 20
VDD_PADS (2.1V to 3.6V)
VDD_PADS (2.1V to 3.6V)
MISO
RES
VDD_PADS
VDD_CORE
VREG_OUT
VDD_PADS
nRESET
nSSEL_INT
SCLK
MOSI
R4
C7 Serial Interface (route to Host uP)
C6
Table 120 contains the bill of materials for the application circuit shown in Figure 12.
82/88
SN260 Table 120. Bill of materials
Item Quantity 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1 2 4 1 1 1 2 1 1 1 1 1 1 1 Reference C2 C1,C3 C4,C5 C6 C7 L1 L2 R1 R2 R3 R4 U1 X1 BLN1 Description Capacitor, 5pF, 50V, NPO, 0402 Capacitor, 0.5pF, 50V, NPO, 0402 Capacitor, 27pF, 50V, NPO, 0402 Capacitor, 10F, 10V, TANTALUM, 3216 (SIZE A) Capacitor, 10pF, 5V, NPO, 0402 Inductor, 2.7nH, +/- 5%, 0603, multi-layer Inductor, 3.3nH, +/- 5%, 0603, multi-layer Resistor, 169 K, 1%, 0402 Resistor, 100 K, 5% O402 Resistor, 3.3 K, 5% 0402 Resistor, 10 K, 5%, 0402 SN260 single-chip Zigbee/802.15.4 solution Crystal, 24.000MHz, +/- 10PPM tolerance, +/25PPM stability, 18pF, - 40C to + 85C BALUN, ceramic
Typical application
Manufacturer/Part No.
MURATA LQG18HN2N7 MURATA LQG18HN3N3
STMicroelectronics SN260 ILSI ILCX08-JG5F18-24.000MHZ TDK HHM1521
83/88
Mechanical details
SN260
10
Mechanical details
The SN260 package is a plastic 40-pin QFN that is 6mm x 6mm x 0.9mm. A large ground pad in the bottom center of the package forms an extra 41st pin. A number of thermal vias should connect the SN260 decal center to a PCB ground plane. For more information, refer to www.stmcu.com. Figure 13 illustrates the package drawing.
Figure 13. Package drawing
Top View
Bottom View D 2 e Detail A
D
3 Pin1 E E1 E2
2x D 1 2x Detail A Edge View Detail B L nx k Nx b 0. 15typ
T
EXPOSED PAD
Notes 1. JEDEC ref M - 220 O 2. All dim ensions are in m eters illim 3. Pin 1 orientation identified by cham on corner of fer exposed die pad . 4. Datum C and the seating plane are defined by the flat surface of the m etallised term inal 5. Dim ension 'e' represents the term inal pitch 6. Dim ension b applies to m etallised term inal and is m easured 1. 25 to1.30 m from term m inal tip . 7. Dim ension L 1 represents term inal pull back from package edge. W here term inal pull back exists only upper half of lead is , visible on package edge due to half etching of leadfram .e 8. Package surface shall be m atte finish 1. 6- 2.2 , Ra 9. Package warp shall be 150 m 1. axim um 10. Leadfram m e aterial is copper194 A. 11. Coplanarity applies to the exposed pad as well as the term inals . Com on Dim m ensions m (m )
M inim um 0.85 0 5.90 4.21 5.91 4.21 0.35 0.18 1.2 b m /2 in N inal om 1.90 1.02 0. 20ref 6.11 4.5 BSC 4.31 6.10 4.5 BSC 4.31 0.41 1.23 40 0.50 0.15
6
Nx
Detail B
0.4000
0.27 typ
4
Sym . A A 1 A 3 D D 1 D 2 E E 1 E 2 L L1 b N e k R T
M axim um 1.0 1.05 6.10 4.41 6.10 4.41 1.45 0.1 0.31
R
0.4000 A 3 L1 7 A 1
Sym . aaa bbb ccc
Tolerances for Form& Position
0.15 0.10 0.10
Notes
84/88
SN260
Ordering information
11
Ordering information
Use the following part numbers to order the SN260:

SN260QT Reel, RoHS SN260Q Tray, RoHS
To order parts, contact your local STMicroelectronics sales representative, or go to our Web site: www.st.com.
85/88
Abbreviations and acronyms
SN260
12
Abbreviations and acronyms
Table 121. Abbreviations and acronyms
Acronym/abbreviation ACR AES CBC-MAC CCA CCM CCM* CSMA CTR EEPROM ESD ESR FFD FIA GPIO HF I2C IDE IF IP3 ISR kB kbps LF LNA LQI MAC MSL Msps O-QPSK PA PER PHY Adjacent Channel Rejection Advanced Encryption Standard Cipher Block Chaining--Message Authentication Code Clear Channel Assessment Counter with CBC-MAC Mode for AES encryption Improved Counter with CBC-MAC Mode for AES encryption Carrier Sense Multiple Access Counter Mode Electrically Erasable Programmable Read Only Memory Electro Static Discharge Equivalent Series Resistance Full Function Device (ZigBee) Flash Information Area General Purpose I/O (pins) High Frequency (24MHz) Inter-Integrated Circuit bus Integrated Development Environment Intermediate Frequency Third order Intermodulation Product Interrupt Service Routine Kilobyte kilobits/second Low Frequency Low Noise Amplifier Link Quality Indicator Medium Access Control Moisture Sensitivity Level Mega samples per second Offset-Quadrature Phase Shift Keying Power Amplifier Packet Error Rate Physical Layer Meaning
86/88
SN260 Table 121. Abbreviations and acronyms (continued)
Acronym/abbreviation PLL POR PSD PSRR PTI PWM RoHS RSSI SFD SIF SPI UART VCO VDD Phase-Locked Loop Power-On-Reset Power Spectral Density Power Supply Rejection Ratio Packet Trace Interface Pulse Width Modulation Restriction of Hazardous Substances Receive Signal Strength Indicator Start Frame Delimiter Serial Interface Serial Peripheral Interface Universal Asynchronous Receiver/Transmitter Voltage Controlled Oscillator Voltage Supply Meaning
References
13
References

IEEE 802.15.4-2003 (standards.ieee.org/getieee802/download/802.15.4-2003.pdf) IEEE 802.11g (standards.ieee.org/getieee802/download/802.11g-2003.pdf) Bluetooth Specification v1.2 (www.bluetooth.org/spec) ZigBee Specification v1.1 (www.zigbee.org; document number 053474r07) ZigBee Security Services Specification v1.0 (www.zigbee.org; document number 03322r13)
14
Revision history
Table 122. Document revision history
Date 11-Dec-2006 3-Dec-2007 Revision 1 2 Initial release. Document status promoted from Preliminary Data to Datasheet. Changes
87/88
SN260
Please Read Carefully:
Information in this document is provided solely in connection with ST products. STMicroelectronics NV and its subsidiaries ("ST") reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described herein at any time, without notice. All ST products are sold pursuant to ST's terms and conditions of sale. Purchasers are solely responsible for the choice, selection and use of the ST products and services described herein, and ST assumes no liability whatsoever relating to the choice, selection or use of the ST products and services described herein. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. If any part of this document refers to any third party products or services it shall not be deemed a license grant by ST for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoever of such third party products or services or any intellectual property contained therein.
UNLESS OTHERWISE SET FORTH IN ST'S TERMS AND CONDITIONS OF SALE ST DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY WITH RESPECT TO THE USE AND/OR SALE OF ST PRODUCTS INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION), OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS EXPRESSLY APPROVED IN WRITING BY AN AUTHORIZED ST REPRESENTATIVE, ST PRODUCTS ARE NOT RECOMMENDED, AUTHORIZED OR WARRANTED FOR USE IN MILITARY, AIR CRAFT, SPACE, LIFE SAVING, OR LIFE SUSTAINING APPLICATIONS, NOR IN PRODUCTS OR SYSTEMS WHERE FAILURE OR MALFUNCTION MAY RESULT IN PERSONAL INJURY, DEATH, OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE. ST PRODUCTS WHICH ARE NOT SPECIFIED AS "AUTOMOTIVE GRADE" MAY ONLY BE USED IN AUTOMOTIVE APPLICATIONS AT USER'S OWN RISK.
Resale of ST products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by ST for the ST product or service described herein and shall not create or extend in any manner whatsoever, any liability of ST.
ST and the ST logo are trademarks or registered trademarks of ST in various countries. Information in this document supersedes and replaces all information previously supplied. The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners.
(c) 2007 STMicroelectronics - All rights reserved STMicroelectronics group of companies Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan Malaysia - Malta - Morocco - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States of America www.st.com
88/88

▲Up To Search▲

Price & Availability of SN260

	To Download SN260 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .